php-fpm 应优先选 static 模式：低并发时避免 dynamic 频繁 fork/kill 带来的调度开销和内存碎片，更适合 wordpress、thinkphp 等短请求、qps 稳定的中小站点；仅在含长连接或常驻脚本时用 dynamic，并调大起始与最小空闲进程数；禁用 ondemand。
PHP-FPM 进程管理模式选 static 还是 dynamic？
宝塔面板默认用 dynamic 模式，但多数中小站点实际更需要 static。原因很简单：dynamic 在低并发时频繁 fork/kill 子进程，反而增加内核调度开销和内存碎片；而 static 启动即固定进程数，响应更稳，尤其适合 WordPress、ThinkPHP 等单请求耗时较短、QPS 波动不大的场景。
实操建议：
- 若服务器内存 ≥ 2GB 且 PHP 应用无明显内存泄漏，直接设为
static，配合固定pm.max_children - 若站点含大量长连接（如 WebSocket 接口）、或有定时脚本常驻运行，保留
dynamic，但必须调大pm.start_servers和pm.min_spare_servers，避免冷启动抖动 - 绝对不要用
ondemand—— 宝塔 8.x+ 虽支持，但其子进程启停延迟高，HTTP 超时风险陡增
pm.max_children 不是越大越好，怎么算才合理？
盲目调高 pm.max_children 是宝塔用户最常踩的坑，结果不是 OOM 就是 MySQL 连接池被打爆。真实值取决于单个 PHP Worker 的平均内存占用，而非 CPU 核心数。
操作步骤：
- 先用
ps aux --sort=-%mem | grep php-fpm查看当前活跃 worker 的 RSS 内存（单位 KB），取中位数 - 假设平均占 45MB，服务器可用内存 1.5GB（预留 512MB 给系统和 MySQL），则最大值 ≈ (1536 − 512) × 1024 ÷ 45000 ≈ 23，向下取整为
20 - 在宝塔 PHP 设置 → 配置修改 → 找到
pm.max_children，填入计算值，重启 PHP-FPM - 上线后观察
pm.status_path输出的active processes峰值，若长期 > 80% max_children，再微调
宝塔改完配置不生效？重点检查这三个位置
宝塔界面上点“保存”只是写入模板，真正生效要过三关。常见现象是改了 pm.max_children 却发现 php-fpm -t 报错，或 systemctl status php-fpm-xx 显示仍在用旧值。
必须逐个确认：
- 宝塔后台 PHP 版本页 → “设置” → “配置修改”，改的是当前版本的主配置文件，路径类似
/www/server/php/80/etc/php-fpm.conf，不是www.conf - 检查
include是否被覆盖：打开php-fpm.conf，确认末尾有include=/www/server/php/80/etc/php-fpm.d/*.conf，且www.conf里没重复定义pm.*参数（冲突时以最后加载的为准） - 重启命令必须带版本号：执行
service php-fpm-80 reload（把 80 换成你实际版本），别只点面板上的“重载配置”，它有时只 reload 不 restart
为什么调了 pm.start_servers 还是卡顿？看慢日志定位真因
即使 pm.start_servers 设对了，用户仍可能遇到首屏加载慢、AJAX 超时。这时候大概率不是 FPM 进程不够，而是 PHP 脚本本身阻塞，比如未加索引的 MySQL 查询、file_get_contents 同步请求第三方 API、或 session_write_close 没调用。
关键动作：
- 开启 PHP 慢日志：
slowlog = /www/wwwlogs/php_slow.log+request_slowlog_timeout = 2s（宝塔 PHP 设置 → 配置修改里直接勾选“显示慢日志”并填超时时间） - 触发一次卡顿操作后，立刻查
tail -n 50 /www/wwwlogs/php_slow.log，重点关注script_filename和backtrace行 - 若日志里反复出现同一接口，且堆栈停在
mysqli_query或cURL，说明问题在业务逻辑，FPM 参数再怎么调也白搭
进程管理策略只是水龙头，水管里流什么水，得看 PHP 脚本自己干了什么。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
