如何基于可用内存正确计算PHP-FPM的pm.max_children配置值

1. 内存统计逻辑错误（最核心问题） #

你用ps命令统计的RSS（常驻内存集）包含了进程间共享的内存段，并非单个PHP-FPM进程的独占内存。
PHP-FPM的子进程会继承主进程的大量只读内存页，包括PHP核心二进制文件、已加载的扩展代码、OPcache缓存的脚本字节码、公共配置等，这些内容所有子进程共用一份，不会每个进程单独占用内存。你直接累加所有子进程的RSS时，会把共享内存部分重复计算N次（N为进程数），导致你严重高估了单进程的实际内存开销，这也是200个进程按31MB/进程计算应该占6GB内存、实际仅占900MB的核心原因。

2. 忽略了内存占用的动态特性 #

你统计的31MB是低负载/空闲状态下的进程平均内存，实际处理业务请求时，进程会根据逻辑动态分配临时内存（比如加载大数组、处理大文件、拉取数据库大结果集等），峰值内存会远高于空闲状态的平均值。如果按空闲值配置pm.max_children，高负载下可能出现内存耗尽的风险，你当前测试场景下还未触达这个阈值而已。

3. 混淆了max_children告警的触发条件 #

pm.max_children告警的触发逻辑是并发请求数超过了可用PHP-FPM进程数，和内存剩余量没有直接关系。如果你的业务IO等待占比很高（比如慢SQL、第三方接口调用耗时久），进程会长时间卡在IO等待状态无法释放，哪怕服务器内存还有大量剩余，也会很快打满pm.max_children上限。这种场景下单纯调高pm.max_children反而会导致请求堆积、服务响应变慢，需要优先优化业务耗时逻辑。

• 内存统计用ps_mem、smem这类可以区分共享内存和独占内存的工具，统计所有PHP-FPM进程的总独占内存，除以进程数得到单进程平均独占内存，再加上固定的共享内存开销，最终用你规划分配给PHP-FPM的内存（需要预留出系统、Web服务、数据库等其他进程的内存空间，不要占满全部可用内存）除以单进程平均独占内存，得到合理的pm.max_children参考值。
• 结合业务类型调整：CPU密集型业务pm.max_children建议不超过CPU核心数的2倍，避免进程上下文切换开销过高；IO密集型业务可以适当调高，但需要配合压测观察请求耗时、错误率的变化，不要无限制上调。
• 配套调整PHP-FPM其他参数：根据并发场景搭配调整pm.start_servers、pm.min_spare_servers、pm.max_spare_servers，设置合理的pm.process_idle_timeout自动释放长时间空闲的进程，提升资源利用率。

内容的提问来源于stack exchange，提问作者jsjw