PHP-FPM 进程数暴增未必是 pm.max_children 设置不当，主因常为 dynamic 模式下 pm.min_spare_servers 和 pm.max_spare_servers 设值过大导致空闲进程堆积；ondemand 模式虽省内存但冷启动延迟高、易引发502，不适用于WordPress等重型PHP应用；优化应先排查xdebug、插件阻塞及错误日志，再权衡吞吐、延迟与内存做针对性调整。
PHP-FPM 进程数暴增，pm = dynamic 是罪魁祸首？
不是所有高进程数都该调 pm.max_children。宝塔默认用 pm = dynamic，但它的三个参数 pm.start_servers、pm.min_spare_servers、pm.max_spare_servers 如果设得过大（比如全设成 20+），PHP-FPM 启动后会直接拉起大量空闲子进程，看着像“卡死”或“占满 CPU”，其实只是在等请求——而你根本没那么多并发。
- 查当前实际进程：运行
ps aux | grep "php-fpm: pool" | wc -l，减去 1（主进程）就是真实 worker 数 - 看是否空闲过剩：用
php-fpm -t && php-fpm -i | grep -E "(pm|memory)"确认配置加载路径和生效值 - 新手最常抄的“优化模板”里把
pm.min_spare_servers和pm.max_spare_servers都设成 15，结果低流量站点也常年维持 15 个 idle 进程，白占内存
pm = ondemand 真的适合小站？别被名字骗了
pm = ondemand 听起来省资源，但它每次请求进来都要 fork 新进程，冷启动延迟明显，且频繁 fork 会抬高系统负载（尤其磁盘 I/O 压力）。对 WordPress、Typecho 这类单次请求需加载几十个 PHP 文件的站点，反而更容易触发超时或 502。
- 适用场景极窄：只有纯 API 接口、QPS
- 必须同步调
pm.process_idle_timeout，否则进程永不回收；宝塔界面不暴露这个字段，得手动改/www/server/php/{版本}/etc/php-fpm.d/www.conf - 注意
pm.max_requests设太小（如 500）会导致进程频繁重启，日志里刷屏WARNING: [pool www] child 12345 exited on signal 15 (SIGTERM) after ... seconds from start
内存爆了，光调 pm.max_children 没用
一个 PHP-FPM worker 平均吃多少内存，取决于你的代码——开 Xdebug、加载 Laravel 全栈、用 file_get_contents 读大文件，都会让单进程从 20MB 涨到 80MB+。这时候硬把 pm.max_children 从 30 改成 10，可能只是把 OOM 杀进程的时间推迟几分钟。
- 先定位谁吃内存：
top -u www看 RES 列，挑几个高值进程记下 PID，再用cat /proc/{PID}/stack看它卡在哪行 PHP - 宝塔的“内存限制”其实是 PHP 的
memory_limit，和 FPM 进程数无关；真正管总内存的是 Linux 的 cgroup 或宿主机物理内存 - 更稳妥的做法是：保持
pm.max_children在安全水位（比如 1GB 内存机器设 12），然后用opcache.enable=1+opcache.memory_consumption=128降低重复加载开销
改完配置不生效？宝塔的 reload 有坑
宝塔面板点“重载配置”看似可靠，但它底层执行的是 systemctl reload php-fpm-{版本}，而很多老版本 PHP-FPM（如 7.2）对 reload 支持不完整，旧 worker 不退出，新配置不加载，你看到的还是旧行为。
立即学习“PHP免费学习笔记（深入）”；
- 最稳做法：先在宝塔里“停止”PHP-FPM，再“启动”，强制全量重启
- 确认生效：改完立刻跑
kill -SIGUSR2 $(cat /www/server/php/{版本}/var/run/php-fpm.pid)（仅限支持 SIGUSR2 的版本），再看ps输出进程数是否重置 - 宝塔 8.x+ 在“PHP 设置 > 高级设置”里藏了个“平滑重启”，勾选它才真正走 graceful restart，否则 reload 就是假的
调 FPM 本质是在吞吐、延迟、内存之间找平衡点，而不是追求“进程数最少”。很多问题根子不在 FPM，而在没关掉开发环境的 xdebug.mode=debug，或者 WordPress 插件偷偷 file_get_contents 拉外部接口卡住进程。先看日志里是 child exited with code 0 还是 segfault，比盲目调参重要得多。
