pm.max_children必须按实测PHP进程RSS内存倒推计算：先用ps命令查平均RSS（如38MB），预留30%系统内存后，用可用内存÷RSS再打八折得安全值（如4GB内存→设56–60），设错会引发OOM或502；调参前须启用pm.status_path和slowlog定位真实瓶颈。
pm.max_children 不是调大就能解决并发差，设错反而更快 502 或 OOM。 它必须按当前 PHP 进程真实内存占用倒推，而不是照着 CPU 核数或宝塔默认值硬填。
怎么查单个 php-fpm 进程实际吃多少内存
宝塔里看「PHP 设置 → 性能调整」显示的 pm.max_children=50 是虚的——你得先知道每个进程到底占多少 RSS（常驻内存）：
- 在 SSH 执行：
ps --no-headers -o rss -C php-fpm | awk '{sum+=$1} END {print int(sum/NR/1024)" MB"}'，结果比如38 MB - 如果开了 Xdebug、Laravel、大量 Composer 包或 fileinfo/exif，实测可能到
60–80 MB；没开扩展的小站可能才22 MB - 别信“平均 30MB”这种经验数，
ps aux --sort=-%mem | grep php-fpm | head -n 5看 RSS 列更准
pm.max_children 应该设多少才不爆又不卡
公式不是拍脑袋：可用内存 ÷ 单进程 RSS，再打八折留余量。例如：
- 服务器总内存 4GB → 预留 30% 给系统、MySQL、宝塔 → 可用约
2800 MB - 实测单进程
38 MB→floor(2800 / 38) ≈ 73→ 建议设pm.max_children = 56–60（打八折） - 设成
100？那光 PHP 就要吃掉3.8GB+，系统立刻开始杀进程（OOM killer） - 宝塔界面改完后，必须点「重载配置」，只「保存」不生效；改前先用
php-fpm -t校验语法
为什么调了 pm.max_children 还是 502 或超时
90% 的情况根本不是 pm.max_children 不够，而是其他环节堵死：
立即学习“PHP免费学习笔记（深入）”；
- 检查
pm.status_path是否启用（宝塔默认关），启用后用curl http://127.0.0.1/status?full看active processes是否真逼近上限 - 翻
/www/wwwlogs/php_slow.log，如果大量请求duration > 1000，说明是脚本慢，加进程只会让内存更快耗尽 -
fastcgi_read_timeout在 Nginx 配置里默认 60 秒，若 PHP 真要跑 90 秒，Nginx 主动断连，报 502——得同步调大 - 数据库连接池空、Redis 超时、
file_get_contents外部 API 没设timeout，都会卡住整个进程，这类问题调pm.max_children完全无效
真正卡点往往藏在 slowlog 和 status_path 里，而不是参数数字本身。调参前，先确认是不是真有那么多活跃请求在排队，还是只是某几个接口拖垮了全部进程。
