php-fpm的max_children（在www.conf中通常对应pm.max_children）没有固定数值，需要根据服务器总内存、单个php进程的平均内存占用以及并发需求来计算。核心做法是用公式：(服务器可用内存 - 系统预留内存) / 单个php进程平均内存。如果设置过高，会导致服务器频繁swap甚至oom崩溃；设置过低，则在高并发下请求排队，响应变慢。
如何根据内存计算初始值？
计算pm.max_children最直接的方法是监控当前生产环境或测试环境中PHP子进程的内存消耗。你需要先确定服务器上有多少内存可供PHP使用，然后除以每个子进程的平均RSS（物理内存占用）。例如，如果你的服务器有4GB内存，系统和其他服务占用1GB，剩下3GB给PHP，而每个PHP进程平均占用50MB，那么max_children大约可以设为60。这个数值是一个静态上限，意味着无论并发请求多少，同时运行的PHP进程不会超过这个数。
#!/bin/bash
# 获取服务器总内存 (KB)
total_mem=$(free -m | awk '/^MemTotal:/{print $2}')
# 获取已用内存 (KB)
used_mem=$(free -m | awk '/^MemUsed:/{print $2}')
# 估算可用给PHP的内存 (假设预留10%给系统)
available_for_php=$(( total_mem * 90 / 100 ))
# 获取当前PHP-FPM子进程的平均内存 (MB)
# 这里假设我们有一个脚本能输出平均内存，或者手动查看top/htop
# 为了演示，我们假设平均每个进程占用 50 MB
avg_process_mem=50
# 计算 max_children
max_children=$(( available_for_php / avg_process_mem ))
echo "Total Memory: ${total_mem} MB"
echo "Available for PHP: ${available_for_php} MB"
echo "Avg Process Memory: ${avg_process_mem} MB"
echo "Recommended pm.max_children: ${max_children}"
运行上述脚本后，你会得到类似如下的输出结果：
Total Memory: 4096 MB
Available for PHP: 3686 MB
Avg Process Memory: 50 MB
Recommended pm.max_children: 73
这意味着在你的4GB内存服务器上，将pm.max_children设置为73左右是相对安全的起点。请注意，这只是一个基于内存的静态计算，实际生产中还需要结合pm.start_servers、pm.min_spare_servers和pm.max_spare_servers来动态调整空闲进程数量，以平衡启动开销和响应速度。
不同PM模式对配置的影响是什么？
PHP-FPM支持三种进程管理模式：static、dynamic和ondemand。选择哪种模式直接决定了max_children的作用方式。在static模式下，pm.max_children是唯一生效的参数，它定义了始终运行的进程总数，适合负载稳定且可预测的场景。在dynamic模式（默认）下，pm.max_children是硬性上限，但实际运行进程数会在pm.min_spare_servers和pm.max_spare_servers之间波动，由pm.start_servers初始化。这种模式适合大多数Web应用，能更好地适应流量变化。ondemand模式则只在有请求时才创建进程，直到达到max_children，适合流量极低且突发不规律的场景，但可能因进程创建延迟导致首屏响应稍慢。
立即学习“PHP免费学习笔记（深入）”；
; ; Dynamic Mode Configuration Example ; [www] pm = dynamic pm.max_children = 50 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 35
在dynamic模式下，pm.max_children依然代表最大并发处理能力。如果并发请求超过50，新的请求将被放入队列等待，直到有空闲进程释放。因此，即使使用了动态模式，max_children的设置仍然至关重要，它防止了内存溢出。建议在生产环境中启用pm.status_path并定期监控Active processes和Idle processes，如果发现Idle processes经常低于min_spare_servers，说明max_children可能设低了，需要适当调高；反之，如果经常高于max_spare_servers，则可以考虑降低max_children以节省内存。
当出现502 Bad Gateway时如何排查？
当PHP-FPM返回502错误时，最常见的原因之一就是pm.max_children设置过小，导致所有进程都在忙，新请求无法被处理，Nginx等反向代理超时后返回502。另一个常见原因是单个PHP脚本执行时间过长，超过了request_terminate_timeout，导致进程被强制杀死。要排查这个问题，首先检查Nginx的错误日志，确认是否有"upstream prematurely closed connection"或"connect() failed"等字样。接着，查看PHP-FPM的状态页面，如果看到Active processes等于pm.max_children，且Idle processes为0，说明确实达到了并发上限。此时，你应该尝试增加pm.max_children的值，或者优化你的PHP代码以减少单次请求的处理时间。此外，还要检查php-fpm.log，看是否有"server reached pm.max_children setting"的警告，这直接证实了进程数已达上限。
