php-fpm在Linux上的资源占用概览与优化要点
一、资源占用构成与典型特征
- 进程模型与数量：php-fpm采用多进程模型，常见进程管理方式包括static、dynamic、ondemand。进程数直接决定内存与CPU的承载能力；进程过多会导致内存吃紧，过少会在峰值时出现排队与超时。动态模式下可通过pm.start_servers / pm.min_spare_servers / pm.max_spare_servers控制进程池弹性，ondemand在空闲时回收进程以降低常驻内存，但冷启动时可能有延迟。
- 内存占用：单个php-fpm子进程的常驻内存（RSS）取决于代码与扩展，常见区间约20–70MB；实际观测中，项目里出现60–70MB/进程并不罕见。总内存≈“单进程RSS × 并发进程数”，因此“进程数 × RSS”是评估内存是否充足的核心指标。
- CPU占用：当请求包含复杂计算、正则回溯、无限循环、递归或慢SQL/外部API时，CPU会显著升高；若并发过高或锁竞争严重，也会出现CPU打满。
- I/O与后端依赖：频繁的数据库查询、磁盘I/O、网络调用会放大响应时间并间接推高CPU与内存占用；合理使用**缓存（如Redis/Memcached）**与优化查询能明显缓解。
二、快速定位高占用的实用命令
- 进程与资源排行：
- 查看CPU占用最高进程：
ps aux | sort -k3nr | head -n 10
- 查看内存占用最高进程：
ps aux | sort -k4nr | head -n 10
- 交互式观察：
top（按1展开CPU核，按P按CPU排序）。
- 定位具体PHP脚本与慢点：
- 打开php-fpm慢日志：
slowlog = log/$pool.log.slow，设置阈值：request_slowlog_timeout = 3（单位秒），用于捕获执行时间超过阈值的脚本与行号。
- 跟踪系统调用：
strace -p <PID>（或strace -cp <PID>统计），配合lsof -p <PID>、pmap <PID>查看文件与内存映射。
- 进程数量核对：
- 统计worker数量：
ps -ef | grep php-fpm: pool www | wc -l（按实际pool名称调整）。
三、配置层面的优化要点
- 控制并发进程数：
- 估算公式（经验）：进程数 ≈ 内存 / 2 / 单进程RSS；例如1GB内存、单进程30–40MB时，进程数宜控制在10–20。
- 动态模式常用组合示例：
pm = dynamic; pm.max_children = 15; pm.start_servers = 8; pm.min_spare_servers = 6; pm.max_spare_servers = 15。
- 回收长期运行进程的内存：
- 设置pm.max_requests（如500–2000），到达阈值后自动重启worker，释放累积内存与碎片（需权衡重启带来的短暂抖动）。
- 超时与慢执行治理：
- 合理设置request_terminate_timeout（如60–120秒）与request_slowlog_timeout（如3–10秒），及时中止异常请求并定位慢点。
- 进程模型选择：
- static适合大内存、高并发、追求稳定的场景；dynamic更灵活，适合资源受限环境；ondemand常驻内存最低，但高峰时可能因冷启动导致504或延迟上升。
四、监控与容量规划建议
- 启用php-fpm状态页：在配置中开启pm.status_path = /status，通过HTTP访问可获取连接数、排队、进程池状态等实时指标，便于容量评估与告警。
- 基础监控项：建议持续采集进程数量、CPU占用率、RSS总内存、单进程RSS、服务存活状态等；可基于脚本（如Shell）采集并接入Zabbix等监控系统，设置阈值告警与趋势分析。
- 容量判断要点：
- 内存：确保“单进程RSS × 最大并发进程数”留有充足余量（含系统与其他服务）。
- CPU：高峰期的平均/峰值CPU应低于核心数，且具备持续余量；若CPU长期接近满载，需优化代码/SQL或扩容。
- 响应：结合慢日志与502/504错误，验证进程数、超时与后端性能是否匹配目标SLA。