聊聊 PHP-FPM 进程数设置背后的真实逻辑

每次有人在群里问“PHP-FPM 进程数设置多少合适”，总能看到一帮人给出“4核就设32”之类的玄学答案。说实话，如果真照着抄，运气好能跑，运气差分分钟 OOM。进程数从来不是一个孤立数字，它背后站着的是内存、CPU、IO 以及真实的流量模型。今天我们就把这背后的逻辑拆开揉碎聊一聊。

先搞清楚瓶颈在哪里

每个 PHP-FPM 子进程都是一个常驻内存的运行时。你可以用 `ps -ylC php-fpm --sort:rss` 查看单进程真实占用。假设业务是 Laravel 这种“重型框架”，一个进程吃掉 60-80MB 非常正常。一台 4GB 的机器，扣除系统和 MySQL，留给 PHP 的可能只有 3GB。这么一算，同时跑 40 个进程就到天花板了。一旦请求数超过这个水位，内存开始 swap，PHP 会像老牛拉破车一样，任你后端怎么优化都白搭。

所以第一道红线，永远由内存决定。设置 `pm.max_children` 之前，先算你最多能匀出多少内存给 PHP，再除以单进程平均内存。这个结果就是硬上限，谁也别想绕过。

CPU 密集还是 IO 密集？

有了内存上限，接着要回答：你的请求到底在占用什么资源。

如果业务是图片处理、数据批量计算这类 CPU 密集场景，每个进程都在拼命使用计算单元。此时进程数远超 CPU 核数不但没意义，还会因频繁上下文切换导致性能雪崩。这类场景下，进程数接近核数，效果往往最好。

但绝大多数 Web 业务并非如此。一个请求要查数据库、读 Redis、调第三方 API，真正消耗 CPU 的时间可能只有几毫秒，剩下的时间全在等待网络 IO。这段等待时间里，CPU 是空闲的。如果只开核数个进程，那并发稍微一高，后面的请求就只能排队，CPU 却在旁边喝茶。多开一些进程，让一部分请求在等待 IO 时，另外一些能借助空闲 CPU 来计算，吞吐量自然就上去了。这也是为什么很多常规架构里，进程数设置为核数的 4 倍、8 倍还能跑得不错——本质上是在牺牲少量内存换取更充分的 IO 等待重叠。

pm 模式不只是参数

PHP-FPM 提供了三种进程管理模式：`static`、`dynamic`、`ondemand`。很多人只把它们当成不同的启动方式，其实它们分别对应不同的资源治理策略。

`static` 是固定拉起指定数量的子进程，一启动就全部存活。如果机器内存够大、业务并发相对平稳，这是响应最快的模式，因为省去了创建和销毁进程的成本。`dynamic` 则让 FPM 根据当前请求量动态调整空闲进程数，适合流量有波动但整体可以预测的场景。`ondemand` 则更激进——有请求才拉起进程，空闲超过一定时间就回收，非常适合内存紧张或流量偏低的场景，缺点是峰值前几毫秒可能因进程启动而轻微延迟。

配置这些模式时，最容易犯的错是只盯着 `pm.max_children`。实际上 `pm.min_spare_servers`、`pm.max_spare_servers` 同样重要。它们决定 php-fpm 对流量波动的反应速度，设得太小，进程频繁创建销毁，CPU 全耗在进程管理上；设得太大，又等于变相常驻一堆空闲进程，内存白白浪费。所以，理解业务潮汐，再调这几个值，才叫“设置”，否则就是在撞运气。

让数据替你做决定

与其猜测，不如直接看 FPM 状态页。打开 `pm.status_path`，然后 curl 一下 `/fpm-status`，能看到 `active processes`、`idle processes`、`max_children_reached` 这些关键指标。如果 `max_children_reached` 不是 0，说明已经出现过“没有空闲进程”的瞬间，意味着当前进程数不够，需要加。如果 `active` 长期接近进程总数，同样说明进程数已经见底。

但注意，每次加进程之前，都得回头确认内存是否有余量。纯看状态页不看内存，照样翻车。更靠谱的做法是压测加监控同时上：用 `ab` 或 `wrk` 模拟预期并发，同时开着 `free -m` 看内存余量，再用 `top` 观察 CPU 负载。只有在稳定压力下测出来的上限，才是真正属于你的数值。

总结

PHP-FPM 进程数没有放之四海皆准的标准答案。它的真实逻辑很简单：先算内存能扛住多少并发进程，再判断业务是 CPU 密集还是 IO 密集，以此决定进程数相对核数的放大倍数，最后用状态页和压测数据去持续修正。配置是个动态过程，不是抄作业。敢于测量、理解瓶颈，你的 FPM 才能跑得既稳又准。