PHP-FPM性能瓶颈90%源于pm模式选错与pm.max_children计算错误：static适合内存≥8GB、流量稳定的场景，dynamic适合有波峰的网站，ondemand仅适用于低频环境；pm.max_children必须基于实测RSS和可用内存计算，而非拍脑袋公式。
直接说结论：PHP-FPM 性能瓶颈90%出在 pm 模式选错 + pm.max_children 算错，不是调小就能稳，也不是调大就吞得下流量——关键在匹配内存、CPU 和真实请求特征。
怎么选 pm = static 还是 dynamic？看内存和流量波动
选错模式是性能崩盘的第一步。static 不是“过时”，dynamic 也不是“万能”：
-
static适合：内存 ≥8GB、流量稳定（如内部API、支付回调服务）、单进程 RSS 稳定在 60–100MB。此时pm.max_children固定，无 fork 开销，响应更可预测；pm.start_servers等参数完全失效，别配。 -
dynamic适合：流量有早晚高峰、秒杀、爬虫突袭等明显波峰的网站。但默认值（如pm.start_servers = 2）在4核服务器上根本撑不住冷启动，会瞬间排队超时。 -
ondemand别乱用：只适用于低频访问的后台管理页或测试环境。高并发下反复 fork + exec 的延迟远高于内存开销，实测平均响应多 80–200ms。
pm.max_children 怎么算才不 OOM？必须用实测 RSS
别信“总内存 ÷ 30MB”这种拍脑袋公式。现代 Laravel/Symfony/WordPress 插件堆叠后，一个空闲 php-fpm 进程常驻内存早超 80MB，处理完请求可能涨到 150MB+。OOM 杀手不是预警，是直接 kill。
- 先查真实占用：
ps aux --sort=-%mem | grep 'php-fpm:' | head -5，看 RSS 列（单位 KB），取运行 1 小时后的稳定值，比如 92000KB ≈ 90MB。 - 再算可用内存：用
free -m看available值，减去 OS（留 2GB）、MySQL（看ps aux --sort=-%mem）、Nginx（通常 100–300MB）——别漏掉 Redis 或日志 agent。 - 最后计算：
pm.max_children = floor(可用内存 MB ÷ 单进程 RSS MB)，再打 10%–15% 冗余。例如可用 10GB，单进程 90MB → 10000÷90≈111 → 设为100。
dynamic 模式下 pm.start_servers 等参数怎么设？别抄网上的固定值
这些参数必须联动调，否则空闲进程一会儿满、一会儿光，CPU 在 fork 上白耗。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
立即学习“PHP免费学习笔记（深入）”；
-
pm.start_servers：不是“越多越好”。应 ≈ CPU 核心数 × 2（4核→8，8核→16），确保冷启动时有足够 worker 接第一波请求。 -
pm.min_spare_servers：底线值，低于它就会 fork。设为 CPU 核心数（4核→4），防止轻负载时进程被清光。 -
pm.max_spare_servers：上限值，高于它就 kill 空闲进程。设为pm.start_servers × 2（如 start=8 → max_spare=16），给弹性空间但不过度放任。 -
pm.process_idle_timeout：默认未启用，一旦开启必须 ≥15s。设成 5s 会导致每分钟 fork 几十次，top里%sy（系统态 CPU）飙升到 30%+。
max_requests 和 slowlog 怎么配合防卡死？单独开没用
pm.max_requests 是防内存泄漏的保险丝，request_slowlog_timeout 是定位卡点的探针，两者必须协同：
-
pm.max_requests设 0 = 放任内存缓慢上涨；设 10000 = 泄漏积累太久才重启。生产建议 1000–3000，观察ps中 RSS 是否随运行时间持续上升，升得快就往低调。 -
request_slowlog_timeout = 1s（不是默认 0 或 5s）：阈值太宽泛，日志全是“执行了 4.2s”，看不出哪一行卡住。 -
request_terminate_timeout = 1.5s（必须比 slowlog 大 0.3–0.5s）：否则慢请求写完 slowlog 还占着 worker，新请求全进队列，listen queue持续 >0 就是这个原因。 - 确认
slowlog路径有写权限，且php-fpm -t通过后再systemctl reload php-fpm，否则日志静默丢弃。
最易忽略的一点：所有参数调完，必须用 curl http://yourdomain/fpm-status?full（先配好 pm.status_path）看实时指标。如果 max active processes 长期 >90% pm.max_children，或 listen queue 平均 >5，说明你算的内存上限还是乐观了——这时候要回退去压测单进程 RSS，而不是继续加进程数。
