PHP-FPM 进程数怎么算：pm.max_children 实战

pm.max_children 决定 php-fpm 最多同时跑多少个工作进程。设小了请求排队直到超时，设大了内存被瞬间打爆触发 OOM（系统内存耗尽后的强制杀进程），这个值值得算一遍再填，算过一次，心里就有底了。 计算公式 max_children 约等于"可分配给 PHP 的内存"除以"单进程平均内存"。可分配内存看 free -m 输出里的 available 列，那才是真正能用的量，别拿 total 去减，total 里有一大块是缓存，会被系统随时回收。两个数都要实测，不拍脑袋。 单进程内存怎么测 让业务跑一段时间之后统计： ps --no-headers -o rss -C php-fpm | awk '{s+=$1; n++} END {print s/n/1024 " MB"}' 输出就是单个 php-fpm 进程的平均物理内存占用。这个统计会把 master 进程也算进去，master 占用小、影响不大，想更精确可以先按 ps -ylC php-fpm --sort:rss 看一眼分布，把异常大的样本单独评估。样本要覆盖正常请求，最好包含几笔大请求之后再测，数字才有代表性，每个季度或业务有大变动后重新测一遍。 一组实际数字 一台 2G 内存的机器：系统加 Nginx、MySQL 大约占掉 800MB，available 显示 1GB 出头，能分给 PHP 的按 1GB 保守算。实测单进程 40MB，max_children 取 25 上下，留出尖峰余量。进程模式用 dynamic 时配套参数按比例给：pm.start_servers = 5，pm.min_spare_servers = 3，pm.max_spare_servers = 10。余量按保守算是有原因的——单个进程处理大请求时，内存可能冲到平均值的两三倍。再推演一下促销场景：流量翻倍时 25 个进程很快排队，这是提前就该知道的容量上限，而不是故障当天才发现。 用两个信号验证 配置上线后看两个信号。Nginx 日志出现 upstream timed out 而 PHP 侧 CPU 不高，说明进程不够、请求在排队，可以加 max_children；free -m 里 available 逼近零，说明到顶了，该加内存而不是加进程。进程状态还有更直接的观测口：池里开 pm.status_path = /status，配合 Nginx 把这个路径暴露到内网，active processes、listen queue 实时可查。再配一份慢日志定位慢请求，request_slowlog_timeout 设 3 秒，慢日志会记录超时请求的完整调用栈，先弄清是谁在慢，再决定是调参数还是改代码，这两件事的先后顺序别弄反。