1. 一次线上卡死现场从报警到定位的24小时先从一个真实场景说起。去年某天下午我负责的一个电商后台突然出现少量接口超时报警刚开始只是几个慢请求三五秒后自动恢复大家没太当回事。但十分钟后报警数量指数级增长线上部分页面直接白屏重启PHP-FPM后恢复过半小时又复发。当时第一反应是数据库扛不住了结果打开慢查询日志一看大批SQL执行时间不到10毫秒。又怀疑是Redis连接被打满检查后发现连接数也正常。最后靠strace逐个查看PHP-FPM子进程的系统调用才发现问题根源某个Worker进程卡在了一个外部接口的file_get_contents()调用上已经持续了63秒。而这个接口的超时时间被设置为0也就是永不超时。这个案例完美诠释了PHP默认I/O模型的死穴同步阻塞。一个请求卡住整个Worker进程就闲置在那里干等既不处理其他请求也不主动放弃其他请求只能排队等待空闲Worker。在PHP-FPM这种预派生进程模型下Worker进程数量是固定的由pm.max_children控制一旦几个Worker同时被慢请求占住新请求就全部堆积最终形成雪崩。这篇文章不是讲某一个陌生框架也不是什么新潮技术恰恰是我们每天都在用的PHP和PHP-FPM最基础、最容易被忽略的机制。我会从Worker进程模型聊到阻塞发生的底层原理再给出定位问题和解决问题的完整思路。适合所有使用PHP-FPM部署业务的开发者尤其是对为什么一个慢请求能拖垮整个服务这个问题困惑过的人。2. 解剖PHP-FPM的Worker进程模型默认就是一个萝卜一个坑2.1 FPM启动时发生了什么PHP-FPM启动后会按照配置文件里的pm相关指令创建一批子进程。以最常用的dynamic模式为例pm dynamic pm.max_children 50 pm.start_servers 10 pm.min_spare_servers 5 pm.max_spare_servers 20FPM主进程Master负责监听网络端口默认9000管理子进程生命周期。子进程Worker才是真正执行PHP脚本的实体。每个Worker进程在同一时刻只能处理一个请求从接收到请求开始到输出完整响应结束这一个Worker就属于这个请求独占。用餐厅做类比Master是餐厅经理只管接电话和安排服务员。每个Worker就是一个服务员一次只能服务一桌客人。客人点完菜开始吃服务员就得在旁边候着直到客人结账走人才能服务下一桌。如果有几桌客人故意不走门口排队的客人再多也没服务员去接。这里的关键点是Worker数量上限是固定的。pm.max_children 50意味着整个FPM最多同时处理50个并发请求。第51个请求进来只能在内核的accept队列里排队直到某个Worker释放。2.2 为什么PHP不采用一个进程内多线程处理并发的方案很多人会问既然一次只处理一个请求效率太低为什么PHP-FPM不用线程来提升并发能力或者像Node.js那样用事件循环历史原因占大头。PHP 4时代对线程的支持很不稳定PHP核心团队最终选择了多进程方案而不是多线程。多进程的好处是内存隔离一个请求崩了Segmentation Fault或者内存溢出只会杀掉自己所在的Worker进程不影响其他WorkerMaster会立即fork一个新的Worker替补。这种健壮性对于Web场景非常宝贵。但代价也很明显进程内无法共享内存状态。你说把MySQL连接缓存到内存里供下一个请求复用做不到每个请求结束后该进程的内存状态就全部销毁了实际上PHP的生命周期决定了所有资源在请求结束时会释放这是另一块话题。所以PHP-FPM只能重复地建立和销毁数据库连接、重复加载文件、重复解析类效率和资源开销都不理想。2.3 OPCache是例外但它管不了I/O顺带提一下OPCache。很多人觉得OPCache开了之后PHP不就常驻内存了吗不是的。OPCache只是把PHP脚本编译出来的字节码缓存在共享内存里避免了每次请求重复读取源码-词法分析-语法分析-编译成opcode这个过程。它解决的是CPU密集型开销和I/O阻塞完全是两码事。请求进来OPCache让PHP脚本从编译执行变成了直接执行但执行过程中如果遇到file_get_contents、curl_exec、mysqli_query这些I/O操作进程照样要挂起等待。OPCache管不到这一步。3. 庖丁解牛一个请求从进入FPM到释放Worker的完整旅程3.1 请求的入口与分发以最常见的Nginx PHP-FPM部署为例完整的调用链是这样的Nginx接收HTTP请求根据location规则将.php结尾的请求通过FastCGI协议转发给PHP-FPM监听的地址如unix:/tmp/php-cgi.sock或127.0.0.1:9000。FPM Master进程接收到FastCGI连接从空闲Worker池里挑一个Worker把请求交给它。Worker进程开始执行初始化PHP环境加载配置文件php.ini、扩展php-fpm.conf中的extension加载OPCache缓存然后按照URL找到对应的PHP脚本。PHP脚本开始执行此时会根据代码逻辑产生各种I/O操作。所有输出收集完毕后Worker通过FastCGI协议把响应内容返回给Nginx。Nginx将响应返回给客户端连接关闭Worker回到空闲池等待下一个请求。这个过程看起来简单但每一步都有阻塞点。3.2 Worker进程执行PHP脚本时的内幕在PHP的执行模型里请求生命周期包含几个阶段RINIT请求初始化、RSHUTDOWN(请求关闭、MINIT模块初始化、MSHUTDOWN模块关闭。其中MINIT和MSHUTDOWN只执行一次FPM启动和结束RINIT和RSHUTDOWN在每次请求都会执行。关键来了RSHUTDOWN阶段PHP会释放本次请求产生的所有资源包括数据库连接、文件句柄、Session锁等。这意味着即便你想在两次请求之间复用一个持久化连接PHP默认也不会让你这么做。每次请求都是全新开始这也是PHP-FPM模型资源开销大的重要原因。3.3 卡住的本质进程的状态机只有运行和等待如果你用ps aux去查看一个正在处理请求的Worker进程它的状态大概率是Ssleeping而不是R(running。为什么因为CPU大部分时间都在等待I/O完成进程被操作系统挂起让出CPU时间片。这个等待是整个文章的核心。操作系统对进程的行为管理非常基础进程发起系统调用去读一个文件、读一个网络包如果数据没有准备好进程调用nanosleep或者select/poll/epoll_wait进入睡眠状态。等数据准备好了内核会把进程唤醒进程再继续执行。问题在于PHP脚本里的代码是顺序执行的。一个curl_exec()没有返回下面100行代码就不会执行。这个Worker就在等待中被挂起。如果这个等待永无止境比如没有设置超时时间的外部接口这个Worker就永远挂在那个系统调用上。pm.max_children又限制了Worker总数结果就是服务并发能力被一步步蚕食。我用一个表格来直观展示不同I/O操作会卡在哪里I/O操作等待的系统调用常见卡死原因file_get_contents(http://...)connect、recvfrom目标服务器无响应无超时时间curl_exec()sendto、recvfrom、poll外部接口处理时间过长mysqli_query()read读socket数据库慢查询、锁等待Redis-get()read读socketRedis阻塞命令如KEYS *、网络分区session_start()flock等待文件锁同一Session的另一个请求未释放锁file_put_contents()fsync、fdatasync磁盘I/O故障、存储饱瓶颈3.4 一个真实的阻塞链路推演假设我们有一个接口/order/create它内部做了以下事情public function create() { // 1. 校验用户身份查Redis $user $this-redis-get(user: . $this-uid); // 2. 查询商品库存查MySQL $inventory $this-db-query(SELECT stock FROM goods WHERE id . $id); // 3. 调用第三方物流接口 $shippingFee $this-httpClient-post(https://api.shipping.com/calc, $payload); // 4. 生成订单再次写MySQL $this-db-exec(INSERT INTO orders ...); // 5. 清理购物车Redis $this-redis-del(cart: . $this-uid); }如果第2步的MySQL查询因为某个大事务长时间未提交导致锁等待这个Worker就卡在了read系统调用上。假设有50个并发请求都卡在同一个锁上50个Worker全部占满FPM彻底无法处理新请求。更隐蔽的是第3步。如果第三方物流接口一直不返回对方服务器出问题而代码里没设置超时这个Worker也会挂死。这种问题排查起来比数据库锁更难因为外部服务不在你的监控范围内你甚至不知道它已经出问题。4. 卡住的根源同步阻塞I/O与进程资源的边界4.1 同步阻塞的含义程序视角 vs 系统视角从程序员的角度看file_get_contents()隐藏了所有细节好像一行代码马上就能拿到结果。但从操作系统的角度看这个函数内部经历了大致如下步骤DNS解析可能阻塞几十毫秒到几秒发起TCP连接可能阻塞几十毫秒到几秒发送HTTP请求几乎瞬时等待响应可能阻塞几秒到永不超时读取响应体按TCP窗口大小分批次读取任何一个步骤的耗时都直接占用Worker进程的生命周期。同步阻塞I/O的模型特征就是I/O操作进行时当前线程/进程的CPU时间被让出但业务逻辑执行权也被冻结。你没法在等待I/O的同时去干别的活儿。4.2 对比事件驱动模型为什么没有这个问题理解一下Node.js的事件循环模型有助于更强烈地感知PHP-FPM模型的限制。Node.js是单线程的但它利用事件循环机制把所有I/O操作都丢给底层线程池libuv自己只负责调度。当某个I/O完成时事件循环触发对应的回调函数继续执行后续代码。用餐厅类比Node.js的服务员不站在某桌客人旁边等而是把菜端上桌记录一下客人A需要加水然后转身去服务客人B。水烧好了、该加水了再去A桌处理。一个服务员就能应对几十桌客人。PHP-FPM不是没有异步能力PHP作为语言层面有pcntl_fork可以fork子进程有stream_select可以做非阻塞I/O监听甚至可以用Swoole扩展实现协程。但默认的PHP-FPM就是同步阻塞模型框架和业务代码都是基于顺序执行、拿到结果再继续的假设编写的。你要让PHP-FPM模式下运行的一堆同步代码变成异步需要大量重构成本极高。4.3 为什么说一个请求卡住整个Worker进程闲置回到题目。闲置这个词用得特别精确。这个Worker进程并不是真的被占用——比如在做大量CPU计算它是空转等待像是一个服务员站在客人旁边看着客人发呆不能去服务别人但实际上什么有用的活儿也没干。ss -tnp可以看到这个进程的TCP连接strace -p PID可以看到它卡在哪个系统调用上shell strace -p 12345 recvfrom(3, 0x7ffc9b6e45f0, 8192, 0, NULL, NULL) -1 EAGAIN (Resource temporarily unavailable) poll([{fd3, eventsPOLLIN}], 1, 30000这个poll等待30秒如果设置的超时是30秒然后循环再来一轮无限等待。这就是卡住Worker的真面目。4.4 进程参数和系统资源的联动除了Worker数量本身还有一些系统层的参数会加剧问题net.core.somaxconn和listen.backlog控制accept队列长度。FPM主进程能排队的未处理连接数是有限的默认backlog可能是128或512。一旦Worker全部占满且accept队列满了新的连接会被内核直接拒绝表现为连接被重置。pm.max_requests每个Worker处理一定数量的请求后自动退出由Master重新fork。这个参数的本意是防止内存泄漏累积但设得过大可能导致一个Worker带病工作很久设得过小会导致频繁创建销毁进程的额外开销。request_terminate_timeout如果设置了这个值Worker执行超过指定时间会被Master强制杀掉。听起来像救命稻草但要注意这个超时是硬杀如果这时正在操作数据库或写文件可能导致状态不一致或者产生僵尸数据。5. 实战排查当请求卡住时如何精准定位阻塞位置5.1 第一时间该拉取的指标发现FPM卡死后先不要急着重启。重启虽然能快速恢复服务但会丢掉现场下次还会踩坑。正确操作是查看当前Worker数量和各状态ps aux | grep php-fpm正常情况有master process和若干pool www进程。如果大量进程同时存在且长时间不退出说明有请求长时间占着Worker。查看FPM状态接口。如果你在php-fpm.conf里配置了pm.status_path就可以通过curl获取curl http://127.0.0.1/phpfpm_status?fullfull参数会列出每个进程的执行状态idle还是running以及每个进程正在执行的脚本路径。看系统负载和mpstat如果%iowait很高很可能是磁盘I/O问题如果%soft高可能是网络包处理太多如果是MySQL的CPU高多半是慢SQL拖垮了MySQL间接拖垮了PHP。5.2 FPM慢日志最省事的定位手段PHP-FPM内置的慢日志功能是排查这个问题最直接的武器。配置如下slowlog /var/log/php-fpm/www-slow.log request_slowlog_timeout 5s当某个请求执行时间超过5秒PHP-FPM就会在慢日志里记录当时的堆栈配置文件里可设置request_slowlog_trace_depth控制深度。堆栈直接告诉你PHP代码执行到哪里卡在哪个函数调用。不过慢日志只能覆盖在PHP代码层面卡住的场景。如果卡在系统调用上比如curl_exec已经进入内核态等待网络数据慢日志依然能记录堆栈让你知道是curl_exec这行前提是PHP函数的调用栈能打出来。实测下curl_exec和file_get_contents等场景慢日志记录到函数名是没问题的。5.3 strace微观视角看系统调用慢日志告诉你卡在哪个PHP函数strace告诉你卡在哪个系统调用两者配合可以精确到具体进程在等什么# 查看PID为12345的Worker进程的系统调用 strace -p 12345 -t -T -e tracenetwork,read,write,select,poll,connect,recvfrom如果卡在connect上说明TCP连接建立阶段超时卡在recvfrom上说明发送请求后等不到响应卡在poll上说明在等待更多的数据到来。-T参数可以显示每个系统调用的耗时帮助你判断是不是长时间停留在这一个调用上。5.4 数据库和缓存的侧写如果pstack显示卡在PDO::query或mysqli_query那就要确定是MySQL的问题还是PHP的问题SHOW FULL PROCESSLIST;这条命令会列出所有正在执行的SQL及其状态。重点关注State字段Waiting for table metadata lock说明有DDL操作阻塞Waiting for row lock说明有行锁冲突Sending data说明在执行大查询。如果是Redis可以用slowlog get查看慢命令。特别注意KEYS *和HGETALL这类大key操作阻塞Redis的同时也会引发PHP的等待。5.5 一次完整的定位过程复盘以开头那个案例继续展开我使用ps aux | grep php-fpm发现10个Worker中有4个处于运行状态R或者SCPU时间在增长但业务日志里没对应请求。使用curl http://127.0.0.1/phpfpm_status?full查看状态页发现4个进程对应的请求URI各不相同但都超过30秒没结束。查看/var/log/php-fpm/www-slow.log发现两个请求卡在file_get_contents()一个卡在curl_exec()一个卡在mysqli_query()。查看MySQL进程列表mysqli_query对应的SQL其实只执行了1毫秒问题在于PHP进程等待获取MySQL连接时阻塞了。原来数据库连接数已经满了PHP申请不到新连接只能排队等待。分析file_get_contents的目标URL发现是第三方物流接口对方的服务器已经宕机了。由于代码里没设置超时时间它一直等不回来。根源浮出水面第三方接口宕机导致几个Worker被占住这几个Worker持有的MySQL连接迟迟不释放导致新的请求无法获取数据库连接只能排队。新增的请求越来越多排队连接也越来越多最终所有Worker都被拖垮。这种连锁反应很典型单一阻塞点会连带到数据库连接、Redis连接等共享资源形成连锁雪崩。6. 对症下药从代码到架构分层解掉这个死结6.1 代码层强制超时是底线**绝对不允许任何外部资源调用不设超时。**这是PHP-FPM模式下最有价值的防护性编程习惯。看一个反例$content file_get_contents(http://third-party-api.com/get); // 没有设置超时对方不返回这里永远卡住正例$ctx stream_context_create([ http [ timeout 3, // 3秒超时 ignore_errors true, ], ]); $content file_get_contents(https://third-party-api.com/get, false, $ctx);curl设置超时的推荐写法$ch curl_init(); curl_setopt_array($ch, [ CURLOPT_URL $url, CURLOPT_RETURNTRANSFER true, CURLOPT_CONNECTTIMEOUT 3, // 连接超时3秒 CURLOPT_TIMEOUT 5, // 总超时5秒 ]); $result curl_exec($ch);连接超时和总超时都要设置。连接超时只控制建立TCP连接的时间如果服务器接受了连接但不返回数据连接超时不生效还需要总超时兜底。6.2 数据库层从连接池到SQL治理MySQL连接获取也要设置合理的超时。PDO的构造方法支持超时参数new PDO($dsn, $user, $pass, [ PDO::ATTR_TIMEOUT 3, ]);更推荐的方向是引入数据库连接池让PHP-FPM进程申请连接时有明确的等待上限。在云原生环境里这通常通过Proxy层如ProxySQL、MaxScale或专门的连接池服务来解决。SQL层的治理包括慢查询治理、索引优化、锁冲突检测。你在EXPLAIN一个SQL时发现typeALL全表扫描就要警惕是不是业务高峰期拖垮了整个数据库。可以在my.cnf里设置slow_query_log ON long_query_time 1 log_queries_not_using_indexes 16.3 架构层把慢操作挪出请求链路代码设了超时只是止损不是最优解。所有耗时的、不稳定的操作都应该想办法挪出同步请求链路。以刚才的物流费用计算为例这个接口耗时没有准数有时几十毫秒有时几十秒不应该让用户同步等待。可以改成用户提交订单先把订单写入数据库状态记为待计算运费。把订单ID推入消息队列Redis list / RabbitMQ / Kafka。一个后台任务进程或者定时任务从队列里取出订单调用物流接口把运费回填更新订单状态。用户端通过轮询或者刷新页面获取最新状态。这样即便第三方接口宕机吞掉的是后台任务的执行速度对nginx和php-fpm的Worker完全无感。6.4 Worker数量调参的艺术pm.max_children调大能解决问题吗部分解决但是有代价。每个PHP-FPM Worker会占用一定的内存实测Helicopter架构下简单Laravel应用每个Worker约30-60MB裸PHP脚本约10-20MB。50个Worker就是1.5-3GB内存。如果机器只有4GB内存再开50个Worker内存交换到磁盘反而更糟。推荐的调参思路是通过监控确定单个Worker的峰值内存占用用free -m看剩余内存倒推合适的max_children。max_children设计为正常并发峰值的1.5倍即可留出缓冲但不要盲目翻倍。开启pm.status_path观察max_active_children指标看实际达到的并发峰值动态调整。配合Nginx侧limit_req对恶意请求或突发流量做限流避免瞬时流量打满Worker池。6.5 终极方案突破PHP-FPM的模型局限如果你的业务请求量大、依赖外部服务多、对超时容忍低PHP-FPM模型就成为一个瓶颈了。此时可以认真评估这些方案Swoole扩展让PHP脚本运行在常驻内存的进程中利用协程实现异步I/O。同一个Worker进程可以同时处理成千上万个并发请求某个请求卡住不会阻塞其他请求。但对现有代码的侵入性比较大需要项目里没有不能用协程的阻塞代码实际很难。ReactPHP / Amp 等纯PHP异步框架同样能实现事件驱动但生态不够完善生产级使用经验少。将高IO业务用Go/Rust重构常见做法是保留PHP-FPM做管理后台等低并发业务将高并发的部分用Go重构成独立微服务PHP通过HTTP或RPC调用。这个迁移成本可能较高但在长期收益上是值得的。而且更高层次的架构思路是不要把所有的稳定性和性能诉求都压在PHP这一层前面用NginxOpenResty做限流和超时控制后面用消息队列削峰填谷中间的服务做到无状态可水平扩展。PHP-FPM的同步阻塞模型可以不完全被看作是缺陷而是把它放在一个部分业务的位置上统筹架构来规避弱点。7. 真实事故里的经验沉淀我的防护清单最后分享几条我在处理过很多类似事故后总结出的硬性规矩第一条代码规范层面强制要求所有外部I/O必须显式指定超时。我在团队里用PHP_CodeSniffer的Generic.PHP.Syntax段做静态检查只能查语法错误超时问题需要Code Review重点盯。后来写了个简易脚本扫描代码里所有file_get_contents、curl_init、mysqli_connect、new PDO的调用位置要求每个后面必须有超时参数。第二条FPM状态页和慢日志默认打开。我以前觉得慢日志只会在出现问题的时候看后来发现它在排查某个时间段为什么接口慢时价值极高。request_slowlog_timeout设成2-3秒一旦有超过2秒的执行就能记录现场两周后回查日志大概率能提前发现隐患。第三条监控FPM的max_active_children且配置告警。如果发现活跃进程数持续排在max_children的80%以上说明并发处理能力快到临界点了不等卡死再处理。第四条不要依赖request_terminate_timeout做超时兜底。这个超时直接强杀进程有可能导致MySQL连接被异常终止、事务没有提交或者回滚产生不完整的脏数据。它适合作为最后的防御措施不应该替代代码级别的超时设置。做PHP这么多年我越来越觉得**每种技术都有它的边界PHP-FPM的同步阻塞模型恰是它的一个明显边界。**知道边界在哪、怎么绕过边界、怎么在边界内把防护做到位恰恰是庖丁解牛的可行性路径。理解这个模型比盲目追求新框架新特性更能在关键时刻让你冷静地止损。
PHP-FPM同步阻塞：Worker卡死根因与防范实战
1. 一次线上卡死现场从报警到定位的24小时先从一个真实场景说起。去年某天下午我负责的一个电商后台突然出现少量接口超时报警刚开始只是几个慢请求三五秒后自动恢复大家没太当回事。但十分钟后报警数量指数级增长线上部分页面直接白屏重启PHP-FPM后恢复过半小时又复发。当时第一反应是数据库扛不住了结果打开慢查询日志一看大批SQL执行时间不到10毫秒。又怀疑是Redis连接被打满检查后发现连接数也正常。最后靠strace逐个查看PHP-FPM子进程的系统调用才发现问题根源某个Worker进程卡在了一个外部接口的file_get_contents()调用上已经持续了63秒。而这个接口的超时时间被设置为0也就是永不超时。这个案例完美诠释了PHP默认I/O模型的死穴同步阻塞。一个请求卡住整个Worker进程就闲置在那里干等既不处理其他请求也不主动放弃其他请求只能排队等待空闲Worker。在PHP-FPM这种预派生进程模型下Worker进程数量是固定的由pm.max_children控制一旦几个Worker同时被慢请求占住新请求就全部堆积最终形成雪崩。这篇文章不是讲某一个陌生框架也不是什么新潮技术恰恰是我们每天都在用的PHP和PHP-FPM最基础、最容易被忽略的机制。我会从Worker进程模型聊到阻塞发生的底层原理再给出定位问题和解决问题的完整思路。适合所有使用PHP-FPM部署业务的开发者尤其是对为什么一个慢请求能拖垮整个服务这个问题困惑过的人。2. 解剖PHP-FPM的Worker进程模型默认就是一个萝卜一个坑2.1 FPM启动时发生了什么PHP-FPM启动后会按照配置文件里的pm相关指令创建一批子进程。以最常用的dynamic模式为例pm dynamic pm.max_children 50 pm.start_servers 10 pm.min_spare_servers 5 pm.max_spare_servers 20FPM主进程Master负责监听网络端口默认9000管理子进程生命周期。子进程Worker才是真正执行PHP脚本的实体。每个Worker进程在同一时刻只能处理一个请求从接收到请求开始到输出完整响应结束这一个Worker就属于这个请求独占。用餐厅做类比Master是餐厅经理只管接电话和安排服务员。每个Worker就是一个服务员一次只能服务一桌客人。客人点完菜开始吃服务员就得在旁边候着直到客人结账走人才能服务下一桌。如果有几桌客人故意不走门口排队的客人再多也没服务员去接。这里的关键点是Worker数量上限是固定的。pm.max_children 50意味着整个FPM最多同时处理50个并发请求。第51个请求进来只能在内核的accept队列里排队直到某个Worker释放。2.2 为什么PHP不采用一个进程内多线程处理并发的方案很多人会问既然一次只处理一个请求效率太低为什么PHP-FPM不用线程来提升并发能力或者像Node.js那样用事件循环历史原因占大头。PHP 4时代对线程的支持很不稳定PHP核心团队最终选择了多进程方案而不是多线程。多进程的好处是内存隔离一个请求崩了Segmentation Fault或者内存溢出只会杀掉自己所在的Worker进程不影响其他WorkerMaster会立即fork一个新的Worker替补。这种健壮性对于Web场景非常宝贵。但代价也很明显进程内无法共享内存状态。你说把MySQL连接缓存到内存里供下一个请求复用做不到每个请求结束后该进程的内存状态就全部销毁了实际上PHP的生命周期决定了所有资源在请求结束时会释放这是另一块话题。所以PHP-FPM只能重复地建立和销毁数据库连接、重复加载文件、重复解析类效率和资源开销都不理想。2.3 OPCache是例外但它管不了I/O顺带提一下OPCache。很多人觉得OPCache开了之后PHP不就常驻内存了吗不是的。OPCache只是把PHP脚本编译出来的字节码缓存在共享内存里避免了每次请求重复读取源码-词法分析-语法分析-编译成opcode这个过程。它解决的是CPU密集型开销和I/O阻塞完全是两码事。请求进来OPCache让PHP脚本从编译执行变成了直接执行但执行过程中如果遇到file_get_contents、curl_exec、mysqli_query这些I/O操作进程照样要挂起等待。OPCache管不到这一步。3. 庖丁解牛一个请求从进入FPM到释放Worker的完整旅程3.1 请求的入口与分发以最常见的Nginx PHP-FPM部署为例完整的调用链是这样的Nginx接收HTTP请求根据location规则将.php结尾的请求通过FastCGI协议转发给PHP-FPM监听的地址如unix:/tmp/php-cgi.sock或127.0.0.1:9000。FPM Master进程接收到FastCGI连接从空闲Worker池里挑一个Worker把请求交给它。Worker进程开始执行初始化PHP环境加载配置文件php.ini、扩展php-fpm.conf中的extension加载OPCache缓存然后按照URL找到对应的PHP脚本。PHP脚本开始执行此时会根据代码逻辑产生各种I/O操作。所有输出收集完毕后Worker通过FastCGI协议把响应内容返回给Nginx。Nginx将响应返回给客户端连接关闭Worker回到空闲池等待下一个请求。这个过程看起来简单但每一步都有阻塞点。3.2 Worker进程执行PHP脚本时的内幕在PHP的执行模型里请求生命周期包含几个阶段RINIT请求初始化、RSHUTDOWN(请求关闭、MINIT模块初始化、MSHUTDOWN模块关闭。其中MINIT和MSHUTDOWN只执行一次FPM启动和结束RINIT和RSHUTDOWN在每次请求都会执行。关键来了RSHUTDOWN阶段PHP会释放本次请求产生的所有资源包括数据库连接、文件句柄、Session锁等。这意味着即便你想在两次请求之间复用一个持久化连接PHP默认也不会让你这么做。每次请求都是全新开始这也是PHP-FPM模型资源开销大的重要原因。3.3 卡住的本质进程的状态机只有运行和等待如果你用ps aux去查看一个正在处理请求的Worker进程它的状态大概率是Ssleeping而不是R(running。为什么因为CPU大部分时间都在等待I/O完成进程被操作系统挂起让出CPU时间片。这个等待是整个文章的核心。操作系统对进程的行为管理非常基础进程发起系统调用去读一个文件、读一个网络包如果数据没有准备好进程调用nanosleep或者select/poll/epoll_wait进入睡眠状态。等数据准备好了内核会把进程唤醒进程再继续执行。问题在于PHP脚本里的代码是顺序执行的。一个curl_exec()没有返回下面100行代码就不会执行。这个Worker就在等待中被挂起。如果这个等待永无止境比如没有设置超时时间的外部接口这个Worker就永远挂在那个系统调用上。pm.max_children又限制了Worker总数结果就是服务并发能力被一步步蚕食。我用一个表格来直观展示不同I/O操作会卡在哪里I/O操作等待的系统调用常见卡死原因file_get_contents(http://...)connect、recvfrom目标服务器无响应无超时时间curl_exec()sendto、recvfrom、poll外部接口处理时间过长mysqli_query()read读socket数据库慢查询、锁等待Redis-get()read读socketRedis阻塞命令如KEYS *、网络分区session_start()flock等待文件锁同一Session的另一个请求未释放锁file_put_contents()fsync、fdatasync磁盘I/O故障、存储饱瓶颈3.4 一个真实的阻塞链路推演假设我们有一个接口/order/create它内部做了以下事情public function create() { // 1. 校验用户身份查Redis $user $this-redis-get(user: . $this-uid); // 2. 查询商品库存查MySQL $inventory $this-db-query(SELECT stock FROM goods WHERE id . $id); // 3. 调用第三方物流接口 $shippingFee $this-httpClient-post(https://api.shipping.com/calc, $payload); // 4. 生成订单再次写MySQL $this-db-exec(INSERT INTO orders ...); // 5. 清理购物车Redis $this-redis-del(cart: . $this-uid); }如果第2步的MySQL查询因为某个大事务长时间未提交导致锁等待这个Worker就卡在了read系统调用上。假设有50个并发请求都卡在同一个锁上50个Worker全部占满FPM彻底无法处理新请求。更隐蔽的是第3步。如果第三方物流接口一直不返回对方服务器出问题而代码里没设置超时这个Worker也会挂死。这种问题排查起来比数据库锁更难因为外部服务不在你的监控范围内你甚至不知道它已经出问题。4. 卡住的根源同步阻塞I/O与进程资源的边界4.1 同步阻塞的含义程序视角 vs 系统视角从程序员的角度看file_get_contents()隐藏了所有细节好像一行代码马上就能拿到结果。但从操作系统的角度看这个函数内部经历了大致如下步骤DNS解析可能阻塞几十毫秒到几秒发起TCP连接可能阻塞几十毫秒到几秒发送HTTP请求几乎瞬时等待响应可能阻塞几秒到永不超时读取响应体按TCP窗口大小分批次读取任何一个步骤的耗时都直接占用Worker进程的生命周期。同步阻塞I/O的模型特征就是I/O操作进行时当前线程/进程的CPU时间被让出但业务逻辑执行权也被冻结。你没法在等待I/O的同时去干别的活儿。4.2 对比事件驱动模型为什么没有这个问题理解一下Node.js的事件循环模型有助于更强烈地感知PHP-FPM模型的限制。Node.js是单线程的但它利用事件循环机制把所有I/O操作都丢给底层线程池libuv自己只负责调度。当某个I/O完成时事件循环触发对应的回调函数继续执行后续代码。用餐厅类比Node.js的服务员不站在某桌客人旁边等而是把菜端上桌记录一下客人A需要加水然后转身去服务客人B。水烧好了、该加水了再去A桌处理。一个服务员就能应对几十桌客人。PHP-FPM不是没有异步能力PHP作为语言层面有pcntl_fork可以fork子进程有stream_select可以做非阻塞I/O监听甚至可以用Swoole扩展实现协程。但默认的PHP-FPM就是同步阻塞模型框架和业务代码都是基于顺序执行、拿到结果再继续的假设编写的。你要让PHP-FPM模式下运行的一堆同步代码变成异步需要大量重构成本极高。4.3 为什么说一个请求卡住整个Worker进程闲置回到题目。闲置这个词用得特别精确。这个Worker进程并不是真的被占用——比如在做大量CPU计算它是空转等待像是一个服务员站在客人旁边看着客人发呆不能去服务别人但实际上什么有用的活儿也没干。ss -tnp可以看到这个进程的TCP连接strace -p PID可以看到它卡在哪个系统调用上shell strace -p 12345 recvfrom(3, 0x7ffc9b6e45f0, 8192, 0, NULL, NULL) -1 EAGAIN (Resource temporarily unavailable) poll([{fd3, eventsPOLLIN}], 1, 30000这个poll等待30秒如果设置的超时是30秒然后循环再来一轮无限等待。这就是卡住Worker的真面目。4.4 进程参数和系统资源的联动除了Worker数量本身还有一些系统层的参数会加剧问题net.core.somaxconn和listen.backlog控制accept队列长度。FPM主进程能排队的未处理连接数是有限的默认backlog可能是128或512。一旦Worker全部占满且accept队列满了新的连接会被内核直接拒绝表现为连接被重置。pm.max_requests每个Worker处理一定数量的请求后自动退出由Master重新fork。这个参数的本意是防止内存泄漏累积但设得过大可能导致一个Worker带病工作很久设得过小会导致频繁创建销毁进程的额外开销。request_terminate_timeout如果设置了这个值Worker执行超过指定时间会被Master强制杀掉。听起来像救命稻草但要注意这个超时是硬杀如果这时正在操作数据库或写文件可能导致状态不一致或者产生僵尸数据。5. 实战排查当请求卡住时如何精准定位阻塞位置5.1 第一时间该拉取的指标发现FPM卡死后先不要急着重启。重启虽然能快速恢复服务但会丢掉现场下次还会踩坑。正确操作是查看当前Worker数量和各状态ps aux | grep php-fpm正常情况有master process和若干pool www进程。如果大量进程同时存在且长时间不退出说明有请求长时间占着Worker。查看FPM状态接口。如果你在php-fpm.conf里配置了pm.status_path就可以通过curl获取curl http://127.0.0.1/phpfpm_status?fullfull参数会列出每个进程的执行状态idle还是running以及每个进程正在执行的脚本路径。看系统负载和mpstat如果%iowait很高很可能是磁盘I/O问题如果%soft高可能是网络包处理太多如果是MySQL的CPU高多半是慢SQL拖垮了MySQL间接拖垮了PHP。5.2 FPM慢日志最省事的定位手段PHP-FPM内置的慢日志功能是排查这个问题最直接的武器。配置如下slowlog /var/log/php-fpm/www-slow.log request_slowlog_timeout 5s当某个请求执行时间超过5秒PHP-FPM就会在慢日志里记录当时的堆栈配置文件里可设置request_slowlog_trace_depth控制深度。堆栈直接告诉你PHP代码执行到哪里卡在哪个函数调用。不过慢日志只能覆盖在PHP代码层面卡住的场景。如果卡在系统调用上比如curl_exec已经进入内核态等待网络数据慢日志依然能记录堆栈让你知道是curl_exec这行前提是PHP函数的调用栈能打出来。实测下curl_exec和file_get_contents等场景慢日志记录到函数名是没问题的。5.3 strace微观视角看系统调用慢日志告诉你卡在哪个PHP函数strace告诉你卡在哪个系统调用两者配合可以精确到具体进程在等什么# 查看PID为12345的Worker进程的系统调用 strace -p 12345 -t -T -e tracenetwork,read,write,select,poll,connect,recvfrom如果卡在connect上说明TCP连接建立阶段超时卡在recvfrom上说明发送请求后等不到响应卡在poll上说明在等待更多的数据到来。-T参数可以显示每个系统调用的耗时帮助你判断是不是长时间停留在这一个调用上。5.4 数据库和缓存的侧写如果pstack显示卡在PDO::query或mysqli_query那就要确定是MySQL的问题还是PHP的问题SHOW FULL PROCESSLIST;这条命令会列出所有正在执行的SQL及其状态。重点关注State字段Waiting for table metadata lock说明有DDL操作阻塞Waiting for row lock说明有行锁冲突Sending data说明在执行大查询。如果是Redis可以用slowlog get查看慢命令。特别注意KEYS *和HGETALL这类大key操作阻塞Redis的同时也会引发PHP的等待。5.5 一次完整的定位过程复盘以开头那个案例继续展开我使用ps aux | grep php-fpm发现10个Worker中有4个处于运行状态R或者SCPU时间在增长但业务日志里没对应请求。使用curl http://127.0.0.1/phpfpm_status?full查看状态页发现4个进程对应的请求URI各不相同但都超过30秒没结束。查看/var/log/php-fpm/www-slow.log发现两个请求卡在file_get_contents()一个卡在curl_exec()一个卡在mysqli_query()。查看MySQL进程列表mysqli_query对应的SQL其实只执行了1毫秒问题在于PHP进程等待获取MySQL连接时阻塞了。原来数据库连接数已经满了PHP申请不到新连接只能排队等待。分析file_get_contents的目标URL发现是第三方物流接口对方的服务器已经宕机了。由于代码里没设置超时时间它一直等不回来。根源浮出水面第三方接口宕机导致几个Worker被占住这几个Worker持有的MySQL连接迟迟不释放导致新的请求无法获取数据库连接只能排队。新增的请求越来越多排队连接也越来越多最终所有Worker都被拖垮。这种连锁反应很典型单一阻塞点会连带到数据库连接、Redis连接等共享资源形成连锁雪崩。6. 对症下药从代码到架构分层解掉这个死结6.1 代码层强制超时是底线**绝对不允许任何外部资源调用不设超时。**这是PHP-FPM模式下最有价值的防护性编程习惯。看一个反例$content file_get_contents(http://third-party-api.com/get); // 没有设置超时对方不返回这里永远卡住正例$ctx stream_context_create([ http [ timeout 3, // 3秒超时 ignore_errors true, ], ]); $content file_get_contents(https://third-party-api.com/get, false, $ctx);curl设置超时的推荐写法$ch curl_init(); curl_setopt_array($ch, [ CURLOPT_URL $url, CURLOPT_RETURNTRANSFER true, CURLOPT_CONNECTTIMEOUT 3, // 连接超时3秒 CURLOPT_TIMEOUT 5, // 总超时5秒 ]); $result curl_exec($ch);连接超时和总超时都要设置。连接超时只控制建立TCP连接的时间如果服务器接受了连接但不返回数据连接超时不生效还需要总超时兜底。6.2 数据库层从连接池到SQL治理MySQL连接获取也要设置合理的超时。PDO的构造方法支持超时参数new PDO($dsn, $user, $pass, [ PDO::ATTR_TIMEOUT 3, ]);更推荐的方向是引入数据库连接池让PHP-FPM进程申请连接时有明确的等待上限。在云原生环境里这通常通过Proxy层如ProxySQL、MaxScale或专门的连接池服务来解决。SQL层的治理包括慢查询治理、索引优化、锁冲突检测。你在EXPLAIN一个SQL时发现typeALL全表扫描就要警惕是不是业务高峰期拖垮了整个数据库。可以在my.cnf里设置slow_query_log ON long_query_time 1 log_queries_not_using_indexes 16.3 架构层把慢操作挪出请求链路代码设了超时只是止损不是最优解。所有耗时的、不稳定的操作都应该想办法挪出同步请求链路。以刚才的物流费用计算为例这个接口耗时没有准数有时几十毫秒有时几十秒不应该让用户同步等待。可以改成用户提交订单先把订单写入数据库状态记为待计算运费。把订单ID推入消息队列Redis list / RabbitMQ / Kafka。一个后台任务进程或者定时任务从队列里取出订单调用物流接口把运费回填更新订单状态。用户端通过轮询或者刷新页面获取最新状态。这样即便第三方接口宕机吞掉的是后台任务的执行速度对nginx和php-fpm的Worker完全无感。6.4 Worker数量调参的艺术pm.max_children调大能解决问题吗部分解决但是有代价。每个PHP-FPM Worker会占用一定的内存实测Helicopter架构下简单Laravel应用每个Worker约30-60MB裸PHP脚本约10-20MB。50个Worker就是1.5-3GB内存。如果机器只有4GB内存再开50个Worker内存交换到磁盘反而更糟。推荐的调参思路是通过监控确定单个Worker的峰值内存占用用free -m看剩余内存倒推合适的max_children。max_children设计为正常并发峰值的1.5倍即可留出缓冲但不要盲目翻倍。开启pm.status_path观察max_active_children指标看实际达到的并发峰值动态调整。配合Nginx侧limit_req对恶意请求或突发流量做限流避免瞬时流量打满Worker池。6.5 终极方案突破PHP-FPM的模型局限如果你的业务请求量大、依赖外部服务多、对超时容忍低PHP-FPM模型就成为一个瓶颈了。此时可以认真评估这些方案Swoole扩展让PHP脚本运行在常驻内存的进程中利用协程实现异步I/O。同一个Worker进程可以同时处理成千上万个并发请求某个请求卡住不会阻塞其他请求。但对现有代码的侵入性比较大需要项目里没有不能用协程的阻塞代码实际很难。ReactPHP / Amp 等纯PHP异步框架同样能实现事件驱动但生态不够完善生产级使用经验少。将高IO业务用Go/Rust重构常见做法是保留PHP-FPM做管理后台等低并发业务将高并发的部分用Go重构成独立微服务PHP通过HTTP或RPC调用。这个迁移成本可能较高但在长期收益上是值得的。而且更高层次的架构思路是不要把所有的稳定性和性能诉求都压在PHP这一层前面用NginxOpenResty做限流和超时控制后面用消息队列削峰填谷中间的服务做到无状态可水平扩展。PHP-FPM的同步阻塞模型可以不完全被看作是缺陷而是把它放在一个部分业务的位置上统筹架构来规避弱点。7. 真实事故里的经验沉淀我的防护清单最后分享几条我在处理过很多类似事故后总结出的硬性规矩第一条代码规范层面强制要求所有外部I/O必须显式指定超时。我在团队里用PHP_CodeSniffer的Generic.PHP.Syntax段做静态检查只能查语法错误超时问题需要Code Review重点盯。后来写了个简易脚本扫描代码里所有file_get_contents、curl_init、mysqli_connect、new PDO的调用位置要求每个后面必须有超时参数。第二条FPM状态页和慢日志默认打开。我以前觉得慢日志只会在出现问题的时候看后来发现它在排查某个时间段为什么接口慢时价值极高。request_slowlog_timeout设成2-3秒一旦有超过2秒的执行就能记录现场两周后回查日志大概率能提前发现隐患。第三条监控FPM的max_active_children且配置告警。如果发现活跃进程数持续排在max_children的80%以上说明并发处理能力快到临界点了不等卡死再处理。第四条不要依赖request_terminate_timeout做超时兜底。这个超时直接强杀进程有可能导致MySQL连接被异常终止、事务没有提交或者回滚产生不完整的脏数据。它适合作为最后的防御措施不应该替代代码级别的超时设置。做PHP这么多年我越来越觉得**每种技术都有它的边界PHP-FPM的同步阻塞模型恰是它的一个明显边界。**知道边界在哪、怎么绕过边界、怎么在边界内把防护做到位恰恰是庖丁解牛的可行性路径。理解这个模型比盲目追求新框架新特性更能在关键时刻让你冷静地止损。
