PHP-FPM 进程池调优：pm 模式选择

发布时间:2025-12-05 16:32

## 三种模式的对比 PHP-FPM 的 pm 参数决定进程池的形态，三个选项对应三种运营思路。static 固定进程数，启动即满配，响应最稳，内存占用也最恒定；dynamic 按需在上下限之间伸缩，闲时省内存，忙时逐渐爬升，代价是冷启动的进程要现起，高峰初期响应略慢；ondemand 平时零进程，来请求才拉起，内存最省，但每个冷启动请求都要付出进程创建的延迟，流量一上来体验明显劣化。 ## 各自的适用面 内存充裕、流量平稳的站点适合 static，把波动因素提前消化掉；小内存机器上跑多个站点，dynamic 让各池按需分配，是主流选择；ondemand 只适合极低频的内部后台，一天没几个请求的运维面板可以一用，对外业务基本不该选它。dynamic 的参数组里，max_children 是天花板，start_servers 是起点，min_spare 与 max_spare 控制闲置区间，四者要成体系地设，不能孤立看。 ## 按内存估算进程数 进程数不是拍出来的，是算出来的。先取单个进程的平均内存，用单个重业务请求压一轮，从状态页或进程列表读出稳定值，再把总可用内存除以它，得出上限。 ``` ps --no-headers -o rss -C php-fpm | awk '{s+=$1} END {print s/NR}' ``` 这条命令输出当前进程的平均驻留内存，单位是千字节。给系统与其他组件留出余量后，max_children 落在这个除法结果之内，避免高峰期进程把内存顶穿，触发系统的内存回收反而全体变慢。 ## 选择建议 一句话给默认答案：一般业务选 dynamic，按内存除法算好上限；内存富裕且要求稳定选 static；ondemand 慎用。进程数之外还有一个常被忽略的联动项：每个进程能同时处理的请求数，长时间运行后进程内存缓慢增长，达到阈值自动回收进程，设得太大会让单个进程越吃越胖，设得太小则频繁重启进程，按站点实际观察值取中即可。改完参数重启进程池生效，观察状态页的活跃进程数与排队请求数，让高峰时段活跃数贴着上限但不排队，就是合适的档位。顺云云服务器上跑 PHP 站点，先用这套方法定基准，再根据控制台监控曲线微调，比凭感觉改参数可靠得多。