Linux中PHP-FPM的内存优化技巧

Linux中PHP-FPM内存优化技巧

一 快速定位内存占用

• 观察整体内存与进程：使用free -m、top/htop查看内存使用趋势与占用排行；按内存排序可用 top/htop 按下M。
• 聚焦PHP-FPM进程：
  • 统计进程数：ps -fe | grep "php-fpm" | grep "pool" | wc -l
  • 查看RSS（常驻内存）与排序：ps -ylC php-fpm --sort:rss 或 ps -e -o pid,comm,args,pcpu,rsz,vsz,stime,user,uid | grep www | sort -nrk5
  • 计算平均每个进程占用内存（单位MB）：ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%.0fM\n", sum/NR/1024) }'
• 定位请求瓶颈与队列：开启pm.status_path = /status，并用 Nginx 代理访问；关注listen queue（等待队列）与max children reached（达到最大子进程次数），队列不为0或该计数增长说明进程不足或过载。

二 核心配置与计算

• 估算最大子进程数：
  • 公式：pm.max_children ≤ 可用内存 / 单个FPM进程平均RSS。
  • 经验值：每个FPM进程常驻约30–50MB（受框架、扩展、业务代码影响）。例如：8GB内存、按50MB/进程估算，理论上限约160，为稳妥可先设100并压测微调。
• 进程管理模式选择：
  • static：进程数固定，适合大内存、高并发且流量稳定的场景。
  • dynamic：按需伸缩，适合中小内存或波动流量。
  • ondemand：空闲超时回收，极致省内存，但高峰易超时，需谨慎。
• 关键参数建议与关系：
  • pm.start_servers：建议取 min_spare + (max_spare - min_spare)/2。
  • pm.min_spare_servers / pm.max_spare_servers：通常设 min ≈ 平均负载，max ≈ 峰值负载；且需满足 max_spare < max_children。
  • pm.max_requests：进程处理一定请求后自动重启，用于回收长期累积的内存（如500–5000范围，视内存泄漏与稳定性权衡）。
  • request_terminate_timeout / request_slowlog_timeout：前者终止异常长请求，后者记录慢请求便于定位。
  • php_admin_value[memory_limit]：限制单进程脚本内存（如128M），防止个别请求失控。
• 示例（仅示意，需压测后微调）：
  • 场景：2GB内存、平均进程40MB → 估算 max_children ≈ 2×1024/40 ≈ 51，保守取40–45。
  • 动态模式参考：
    • pm = dynamic
    • pm.max_children = 40
    • pm.start_servers = 12（≈ 8 + (24-8)/2）
    • pm.min_spare_servers = 8
    • pm.max_spare_servers = 24
    • pm.max_requests = 1000–2000
    • request_terminate_timeout = 30s
    • request_slowlog_timeout = 5s
    • php_admin_value[memory_limit] = 128M
    • pm.status_path = /status
      以上做法与参数含义、计算思路、模式选择及示例配置，均来自生产调优经验与官方常用配置范式。

三 防止内存“只增不减”

• 周期性重启回收：合理设置pm.max_requests，让进程在达到阈值后重启，释放累积内存（如500–2000；泄漏严重时可更低，但会增加重启抖动）。
• 理解PHP内存回收机制：PHP-FPM在每次请求结束后会回收脚本使用的内存，但进程本身可能出于性能考虑继续持有部分内存，不会立即归还给操作系统；因此“重启进程”是控制常驻内存的有效手段。
• 谨慎使用ondemand：虽然空闲时更省内存，但高峰期可能因频繁创建进程导致504 Gateway Timeout，需结合业务可接受延迟与超时设置权衡。

四 配套优化与监控

• 启用并合理配置OpCache（PHP.ini）：加速脚本执行、减少编译开销，间接降低CPU与I/O压力，提升总体吞吐。
• 打开慢日志与状态页：slowlog与slowlog_timeout定位耗时函数与SQL；pm.status_path观察listen queue、active/idle processes、max children reached等关键指标，作为调参依据。
• 系统层监控与调优：结合htop、vmstat、iostat观察CPU、内存、I/O与队列；必要时优化数据库查询与索引、引入Redis/Memcached缓存、减少阻塞I/O，避免成为FPM上游瓶颈。

五 安全变更与压测流程

• 变更流程：备份原配置 → 只调整一个变量 → 灰度或低峰滚动重启（如systemctl reload php-fpm或restart）→ 观察free/top、FPM状态页与业务指标（95/99分位延迟、502/504、吞吐）→ 逐步迭代。
• 压测建议：使用ab/wrk/siege或真实流量回放，逐步增加并发，观察队列与错误率，验证max_children、spare、max_requests的组合是否满足目标SLA。