合理设置 pm.max_children 需按内存倒推：先查 php-fpm 进程 rss 中间值（如 36mb），预留 30% 系统内存后计算上限并打八折，例如 4gb 总内存得 60；配置须改对版本对应 www.conf 并重载，同时排查慢脚本、超时及连接卡死等真因。
pm.max_children 不是调大就快，而是要按内存倒推——设高了爆 OOM，设低了直接 502。
怎么算出合理的 pm.max_children 值
别信“CPU 核数 × 4”这种拍脑袋算法。PHP-FPM 进程吃的是内存，不是 CPU。每个 php-fpm 子进程常驻 RSS 通常在 25–50MB（装了 Xdebug、Redis、PDO_PGSQL 等扩展会更重），超了就容易触发系统 OOM killer。
实操步骤：
- 先查真实内存占用：
ps aux --sort=-%mem | grep php-fpm | head -n 5，看 RSS 列中间值（比如 36MB） - 留出 30% 给系统、MySQL、宝塔自身（如 4GB 总内存 → 可用约 2800MB）
- 计算上限：
floor(2800 / 36) ≈ 77，再打八折取pm.max_children = 60 - 注意：如果服务器只有 1GB 内存，
pm.max_children设成 10 都可能撑不住，建议从 2–3 起步
为什么改了 www.conf 还是不生效
常见失效场景不是配置写错了，而是没走对流程：
- 确认改的是对应 PHP 版本的
/www/server/php/{版本号}/etc/php-fpm.d/www.conf，不是/www/server/php/{版本号}/etc/php-fpm.conf（后者没有pm.*参数） - 改完必须执行
bt restart php或在宝塔界面点「重载配置」——只点「保存」完全没用 - 验证是否生效：
ps aux | grep php-fpm | wc -l看进程数，或用php-fpm-{版本号} -t检查语法（输出test is successful才算过关） - 别被
php_admin_value[memory_limit]干扰：它管单脚本内存，和进程数无关
pm.start_servers 设太小会导致高并发卡顿
宝塔默认 pm = dynamic，但很多人把 pm.start_servers 设成 2 或 5。结果一到流量高峰，新请求排队等 fork 进程，Nginx 报 upstream timed out，首屏延迟飙到 2s+。
正确做法：
- 进宝塔「网站」→「PHP 设置」→「性能调整」，看「当前运行中进程数」的 5 分钟低谷值（比如稳定在 12–18）
-
pm.start_servers设为该区间的下限（如 12），pm.min_spare_servers设为 8–10 -
pm.max_spare_servers别超过pm.max_children * 0.3，否则空闲时也占着大量内存 - 有定时任务或早高峰突增的站点，
pm.start_servers可比低谷值高 2–3，但绝不能接近pm.max_children
调了 pm.max_children 还是 502？真因往往不在这里
很多用户猛加 pm.max_children 后发现内存更快耗尽、502 更频繁——说明堵点根本不在进程池大小。
优先排查这些：
- 启用
pm.status_path = /status（宝塔默认关），用curl http://127.0.0.1/status?full看真实进程状态，确认是否真达到上限 - 检查
/www/wwwlogs/php_slow.log：大量 >1 秒的慢脚本会把进程池占满，此时加进程只会恶化内存压力 - Nginx 的
fastcgi_read_timeout默认 60 秒，若后端真要跑 90 秒，得同步调大，否则 Nginx 主动断连导致 502 - 数据库连接没设 timeout、
file_get_contents外部 API 无超时、Redis 阻塞——这类卡死问题，调pm.max_children完全无效
最易被忽略的一点：动态模式下 pm.max_requests 设太小（比如 100）会导致频繁重建进程，反而增加 CPU 和内存抖动；建议设为 1000–3000，平衡内存泄漏与开销。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
