PHP 跑得慢，很多人第一反应是换框架、加缓存、上 OPcache，折腾一圈回来发现瓶颈其实卡在 PHP-FPM 这一层。我见过不少线上环境，代码逻辑没大问题，机器配置也不差，但并发一上来响应时间就飙，排查到最后往往是 FPM 的进程管理模式选错了，或者进程参数拍脑袋填的。这篇就围绕PHP-FPM 管理模式选择和进程参数配置这两件事，把我这些年调优踩过的坑和验证过的思路完整拆一遍，从原理到参数计算再到实操落地，尽量让不同基础的朋友都能照着复现。

1. 先搞清楚 PHP-FPM 到底在管什么

1.1 从一次请求的生命周期说起

要理解进程参数，得先明白一个 PHP 请求在 FPM 里是怎么被处理的。FPM 是一个常驻的进程管理器，它自己有一个 master 进程，负责监听端口、管理 worker 池；真正干活的是 worker 进程，每个 worker 在同一时刻只处理一个请求。请求进来后，master 把连接分给空闲的 worker，worker 执行完 PHP 脚本再把结果返回，然后等待下一个请求。

这个模型决定了几个关键事实：第一，worker 数量直接决定了同时能处理多少个请求，也就是并发上限；第二，worker 是常驻的，不像 CGI 那样每个请求 fork 一次，所以省掉了进程创建开销，但代价是每个 worker 都占一份内存；第三，worker 空闲时是否回收、什么时候回收，完全由管理模式决定。你把这三件事想透了，后面的参数配置就是水到渠成的事。

很多人调 FPM 只看pm.max_children一个值，这是典型的只见树木不见森林。max_children 只是结果，真正决定它该填多少的，是内存预算、请求特征和管理模式三者的组合。下面逐个拆。

1.2 master 与 worker 的分工边界

master 进程不处理业务请求，它做的事情包括：读取配置文件、创建监听 socket、fork 出 worker、监控 worker 状态、在 worker 异常退出时补位、处理平滑重载信号。worker 进程则负责 accept 连接、执行脚本、返回响应。这个分工带来的一个重要推论是：master 本身几乎不消耗 CPU，内存占用也很小，所以你在算内存预算时，主要算的是 worker 的数量乘以单个 worker 的常驻内存。

还有一个容易被忽略的点：FPM 的监听 socket 是在 master 里创建的，worker 通过继承拿到这个 socket。这意味着 worker 重启不会导致端口短暂不可用，平滑重载（reload）时新老 worker 会短暂共存。理解这一点，你才能明白为什么pm.max_requests触发的 worker 回收是安全的——回收的是 worker，不是监听本身。

1.3 为什么进程参数值得单独拿出来调

PHP 是同步阻塞模型，一个 worker 卡在数据库查询或者外部接口上时，它是不能去处理别的请求的。这跟异步框架有本质区别。所以 FPM 的并发能力不是靠"事件循环"撑起来的，而是靠"堆 worker"堆出来的。worker 堆少了，请求排队；堆多了，内存吃紧甚至 OOM。这个平衡点找不准，要么浪费资源，要么稳定性出问题。

我实际遇到过的情况是：某业务高峰期响应时间从 200ms 涨到 2s，监控显示 CPU 并不高，内存也够，最后发现是pm.max_children设得太小，请求在 FPM 队列里排队。把参数调大之后响应时间立刻回落。反过来也有案例，max_children 设得过大，机器内存被 worker 吃满，触发系统 OOM killer 把 MySQL 干掉了，连带整个服务雪崩。所以这个参数不是越大越好，是要算出来的。

2. 三种管理模式的选择逻辑

2.1 static 静态模式：稳定但吃内存

static 模式下，FPM 在启动时就一次性 fork 出固定数量的 worker，数量等于pm.max_children，运行期间不增不减。它的优点是行为完全可预测：并发能力恒定，没有 fork 开销，响应延迟稳定。缺点是内存占用是"满配"的，哪怕半夜没人访问，这些 worker 也占着内存不放。

这种模式适合什么场景？我的经验是：流量稳定、可预测、且机器内存充足的服务。比如内部管理系统、定时任务密集的服务、或者流量曲线很平的后台 API。这类场景下，你清楚知道峰值并发大概多少，直接把 worker 数定死，省掉了动态调整的判断开销，延迟表现最稳。

不适合的场景也很明确：流量波动大的对外服务。白天峰值需要 50 个 worker，凌晨可能只有 2 个请求，static 模式下那 48 个空闲 worker 就是纯浪费。如果你的机器是共享的、内存紧张，static 会让你的内存预算非常难看。

2.2 dynamic 动态模式：灵活但有判断成本

dynamic 模式是大多数人的默认选择。它维护一个 worker 池，池的大小在pm.start_servers到pm.max_children之间浮动，根据空闲 worker 数量动态增减。具体逻辑是：master 定期检查空闲 worker 数，如果空闲数低于pm.min_spare_servers，就 fork 新 worker；如果空闲数高于pm.max_spare_servers，就杀掉多余 worker。

这个模式的好处是兼顾了低峰期的内存节约和高峰期的弹性。代价是 fork 和 kill 本身有开销，而且"判断"有延迟——流量突然暴涨时，master 需要时间才能把 worker 补上来，这期间请求可能排队。所以 dynamic 模式对突发流量的响应不是瞬时的，它更适合"有波动但波动可预期"的场景，比如有明显的早晚高峰、但不会一秒内从 10 并发跳到 500 并发的业务。

参数之间的约束关系要特别注意：pm.min_spare_servers必须小于等于pm.max_spare_servers，pm.max_spare_servers必须小于等于pm.max_children，pm.start_servers建议落在 min 和 max spare 之间。这些约束违反了 FPM 启动会直接报错，配置的时候别踩这个坑。

2.3 ondemand 按需模式：省内存但延迟有抖动

ondemand 模式更激进：平时一个 worker 都不留（或者说只留极少数），来请求了才 fork，空闲超过pm.process_idle_timeout秒就杀掉。内存占用是最省的，特别适合那些访问量很低、但偶尔有请求的服务，比如内部工具、低频后台接口、开发测试环境。

但它的缺点也很明显：每个新请求都可能触发 fork，fork 是有成本的（虽然比 CGI 时代低很多，但仍有毫秒级开销），而且冷启动的 worker 没有预热，第一次执行脚本时 OPcache 可能还没命中，延迟会有明显抖动。对于延迟敏感的服务，ondemand 不是好选择。

我个人的判断标准是这样的：如果服务 QPS 长期低于个位数，且对延迟不敏感，用 ondemand 省内存；如果 QPS 中等且有波动，用 dynamic；如果 QPS 高且稳定，用 static。这个标准不是绝对的，但能覆盖大部分场景。

2.4 选型时最容易犯的两个错

第一个错是"无脑 dynamic"。很多人觉得 dynamic 是万金油，所有服务都配 dynamic。但如果你的服务流量其实很稳定，dynamic 反而引入了不必要的 fork/kill 开销和判断延迟，不如 static 干脆。第二个错是"ondemand 省内存"的误解。ondemand 确实省内存，但如果你的服务 QPS 其实不低，频繁 fork 的开销和延迟抖动会抵消掉省内存带来的收益，得不偿失。

选型的本质是回答一个问题：你的服务，是"稳定可预测"还是"低频偶发"还是"波动但有规律"？答案对应 static、ondemand、dynamic。别被默认配置带偏，默认值往往是保守的折中，不一定适合你的实际负载。

3. 进程参数的计算方法与实操

3.1 先算内存预算，再定 max_children

pm.max_children是整个配置里最核心的参数，它决定了 worker 数量的上限。算法其实不复杂：可用内存除以单个 worker 的常驻内存，就是理论上限。但这里有几个细节要抠。

首先，可用内存不是机器的总内存，要扣掉操作系统、数据库、缓存服务、其他进程的占用。假设一台 8G 的机器，MySQL 占了 2G，Redis 占了 1G，系统和其他进程留 1G，那留给 FPM 的大概是 4G。其次，单个 worker 的常驻内存怎么测？最靠谱的办法是压测时用ps或者top看实际 RSS。经验值上，一个加载了常规框架的 PHP worker 大概在 30M 到 80M 之间，具体取决于框架大小、加载的扩展、以及是否用了 OPcache。

假设实测单个 worker 是 50M，可用内存 4G，那pm.max_children的理论上限是 4096 / 50 ≈ 81。但不要直接填 81，要留安全余量，填 70 左右比较稳妥。因为内存会有碎片、会有峰值波动，卡着上限填容易在极端情况下触发 OOM。

提示：测 worker 内存一定要在压测状态下测，空载时的 RSS 会偏小，因为很多内存是请求处理过程中才分配的。

3.2 dynamic 模式下三个 spare 参数怎么配

确定了 max_children，dynamic 模式还要配pm.start_servers、pm.min_spare_servers、pm.max_spare_servers。这三个参数的官方建议是：start_servers 取 min_spare 和 max_spare 之间的值，min_spare 大约是 max_children 的 10% 到 20%，max_spare 大约是 25% 到 50%。

我自己的经验公式更具体一点：min_spare_servers取max_children的 15% 左右，max_spare_servers取 35% 左右，start_servers取两者的中间值。以 max_children=70 为例，min_spare 约 10，max_spare 约 24，start_servers 约 17。这样配置的逻辑是：平时维持 17 个 worker 待命，空闲数低于 10 就补，高于 24 就杀，既不会频繁 fork，也不会留太多闲置。

这里有个实操心得：min_spare 不要设得太小。设成 1 或者 2 看似省内存，但流量稍微一涨，空闲 worker 立刻不够，master 要连续 fork 好几个，这期间的请求会排队。设成 max_children 的 15% 左右，相当于给突发流量留了一个缓冲垫。

3.3 max_requests 的取舍：防内存泄漏还是保性能

pm.max_requests控制一个 worker 处理多少个请求后被回收重建。设成 0 表示永不回收。这个参数的存在意义是防止 PHP 脚本里的内存泄漏（比如某些扩展、某些长生命周期对象）累积导致 worker 内存膨胀。

设多少合适？我的建议是 500 到 1000 之间。设太小（比如 100），worker 频繁重建，fork 开销和 OPcache 冷启动会影响性能；设太大或者设 0，内存泄漏的风险累积。500 到 1000 是一个平衡点，既能定期清理潜在泄漏，又不会造成明显的性能损耗。

判断是否需要调小这个值，有个简单方法：观察 worker 的 RSS 是否随运行时间持续增长。如果跑一天下来 RSS 从 50M 涨到 200M，说明有泄漏，max_requests 要调小；如果 RSS 基本稳定，那 1000 甚至更大都没问题。

3.4 一份可直接参考的配置模板

把上面的逻辑落成配置，大概是这个样子（以 8G 机器、max_children=70 为例）：

; 进程管理模式 pm = dynamic ; worker 数量上限，按内存预算算出 pm.max_children = 70 ; 启动时的 worker 数 pm.start_servers = 17 ; 最小空闲 worker 数 pm.min_spare_servers = 10 ; 最大空闲 worker 数 pm.max_spare_servers = 24 ; 每个 worker 处理 800 个请求后回收 pm.max_requests = 800 ; 单个请求超时时间（秒），防止慢请求拖死 worker request_terminate_timeout = 30 ; 慢日志阈值，超过 2 秒的请求记录 request_slowlog_timeout = 2 slowlog = /var/log/php-fpm/slow.log

这份配置不是让你照抄，而是让你理解每个值背后的计算逻辑。你的机器内存、框架大小、流量特征不同，算出来的值就不同。关键是掌握"内存预算 → max_children → spare 参数"这条推导链。

4. 压测验证与常见问题排查

4.1 配置改完必须压测，别凭感觉上线

参数算得再漂亮，也只是理论值。上线前一定要压测验证。压测的目标不是追求极限 QPS，而是验证两件事：一是在预期峰值并发下，响应时间是否可接受；二是内存占用是否在安全线以内。

压测工具用 ab、wrk 或者 JMeter 都行，关键是压测流量要尽量贴近真实请求——如果真实请求里有数据库查询、有外部接口调用，压测脚本也要模拟这些，否则压出来的结果虚高。压测时同时盯三个指标：QPS、P99 响应时间、FPM 进程的 RSS 总和。如果 P99 明显高于 P50，说明有请求在排队，max_children 可能不够；如果 RSS 总和逼近可用内存，说明 max_children 太大，要往下调。

4.2 常见问题速查表

4.3 几个踩过的坑

第一个坑：request_terminate_timeout设得比 PHP 的max_execution_time还大。这两个超时是不同层面的，FPM 的超时是强杀 worker，PHP 的超时是脚本自己报错退出。如果 FPM 超时设得太大，慢请求会长时间占住 worker，拖垮整体并发。建议 FPM 的超时略大于 PHP 的超时，给脚本自己退出的机会，但不要大太多。

第二个坑：忽略了listen.backlog。这个参数控制等待 accept 的连接队列长度，默认值往往偏小。高并发下如果 backlog 满了，新连接会被拒绝，表现为偶发的连接失败。适当调大（比如 511 或 1024）能缓解这个问题，但要配合操作系统的 somaxconn 一起调。

第三个坑：压测环境和生产环境配置不一致。压测时用了 static 模式跑出漂亮数据，上线却配了 dynamic，结果高峰期 worker 补充不及时。压测的配置必须和生产的配置完全一致，否则压测结果没有参考价值。

5. 监控与持续调优

5.1 打开 FPM 状态页，让数据说话

FPM 自带一个 status 页面，能实时看到当前活跃进程数、空闲进程数、监听队列长度、慢请求数等关键指标。配置方式是在 pool 配置里加：

pm.status_path = /fpm-status

然后在 Nginx 里把这个路径代理到 FPM，限制只允许内网访问。status 页面里的active processes和idle processes是最有用的两个数：active 长期接近 max_children，说明 worker 不够；idle 长期很高，说明 worker 过剩。listen queue大于 0 且持续增长，说明 backlog 或者 worker 数量有问题。

5.2 建立自己的调优节奏

FPM 调优不是一锤子买卖。业务量会变、代码会变、依赖会变，今天合适的参数半年后可能就不合适了。我的做法是：每次大促或者重大版本上线前，重新跑一次压测，核对一遍参数；平时通过监控看 active/idle 的比例，如果 active 长期超过 max_children 的 70%，就考虑扩容或者调参。

还有一个习惯值得养成：把 FPM 的关键配置和计算依据写进文档，注明"这个值是怎么算出来的、基于什么假设"。这样下次调整的时候，你能快速回忆起当时的逻辑，而不是对着一个数字发呆。参数背后的推理过程，比参数本身更有价值。

5.3 什么时候该考虑换架构而不是调参数

最后说句实在话：FPM 调优有天花板。如果你的服务是 IO 密集型、大量时间花在等数据库或者等外部接口上，那堆再多 worker 也只是把等待放大，治标不治本。这种情况下，该考虑的是优化慢查询、加缓存、拆分服务，甚至评估是否需要异步框架。FPM 参数调优解决的是"进程管理层面的效率问题"，解决不了"业务逻辑层面的性能问题"。分清楚这两者，才不会在错误的路上越走越远。

我在实际项目里的体会是，FPM 配置这件事，八成的收益来自把 max_children 和模式选对，剩下两成才是 spare 参数和 max_requests 的微调。先把大头抓住，别一上来就纠结细枝末节。每次改配置只改一个变量，改完压测对比，这样你才能清楚知道每个参数到底带来了什么变化。