怎样优化Linux PHP-FPM内存使用

Linux PHP-FPM内存优化实操指南

一 基线测量与容量边界

• 先看整体内存与进程分布：用free -m、top/htop观察可用内存与占用排行；用ps -ylC php-fpm --sort:rss或ps -e -o pid,comm,args,pcpu,rsz,vsz,stime,user,uid | grep www | sort -nrk5查看 PHP-FPM 进程的 RSS（常驻内存）。计算单个进程平均内存：例如命令ps --no-headers -o “rss,cmd” -C php-fpm | awk ‘{ sum+=$1 } END { printf (“%d%s\n”, sum/NR/1024,“M”) }’，得到如60M/进程的基线。
• 估算安全进程上限：在你的应用下测得单进程 RSS 为M_rss（单位 MB），系统可用内存为Mem_avail（MB），建议的安全并发进程数N_max ≈ Mem_avail / M_rss。例如测得60M/进程、可用1536M，则N_max ≈ 25。该值用于约束pm.max_children，避免 OOM 与 Swap 抖动。
• 观察 FPM 运行状态：开启pm.status_path = /status与可选的ping.path = /ping，通过 Nginx 代理访问，关注listen queue、idle/active processes、max children reached、slow requests等指标，判断是“进程不够”还是“进程太多/太慢”。

二 核心参数设置与计算

• 进程管理模式选择
  • static：进程数固定为pm.max_children，适合内存充足且流量稳定的场景，延迟更稳。
  • dynamic：按需伸缩，适合内存受限或波动较大的环境。
  • ondemand：空闲超时即回收，内存最省，但冷启动与突发流量下易出现504。
• 关键参数与经验公式（dynamic 模式）
  • pm.max_children：上限值，按“可用内存 / 单进程 RSS”计算，并预留**20%–30%**给系统与其他服务。
  • pm.start_servers：建议取min_spare + (max_spare - min_spare)/2。
  • pm.min_spare_servers / pm.max_spare_servers：常见做法是让max_spare ≈ 0.6–0.8 × max_children，并始终满足min_spare < max_spare < max_children。
  • pm.max_requests：进程在处理若干请求后自动重启，用于缓解长期运行后的内存膨胀与泄漏，建议500–5000；并发极高可适当放大，泄漏明显则缩小。
  • request_terminate_timeout / request_slowlog_timeout：前者是 FPM 层面的硬超时（与 php.ini 的max_execution_time取先到者），后者用于抓取慢请求定位问题。
  • php_admin_value[memory_limit]：单个脚本内存上限，如128M，防止异常脚本耗尽进程内存。
• 快速估算示例（仅演示方法）
  • 测得单进程 RSS≈60M，系统可用内存≈1536M → 建议pm.max_children ≈ 1536/60 ≈ 25；取pm.min_spare=5、pm.max_spare=16（约为 max 的64%），则pm.start_servers ≈ 5 + (16-5)/2 ≈ 11。
  • 若测得单进程 RSS≈40M，可用内存≈8G → 粗略上限≈200，保守可设pm.max_children=100，再按负载与监控微调。

三 配置示例与落地步骤

• 示例一 小内存 VPS（约1GB，单进程 RSS≈60M）
  • 思路：控制并发、保留余量、启用回收与监控。
  • 参考配置（/etc/php/*/fpm/pool.d/www.conf）：

    [www]
    pm = dynamic
    pm.max_children = 15
    pm.start_servers = 6
    pm.min_spare_servers = 4
    pm.max_spare_servers = 10
    pm.max_requests = 1000
    request_terminate_timeout = 30
    request_slowlog_timeout = 5
    slowlog = /var/log/php-fpm/slow.log
    php_admin_value[memory_limit] = 128M
    pm.status_path = /status
    listen.backlog = 2048
    

• 示例二 中等内存（约8GB，单进程 RSS≈40M）
  • 思路：并发更高、稳态更稳，适度放大 max_children 与 spare。
  • 参考配置：

    [www]
    pm = dynamic
    pm.max_children = 100
    pm.start_servers = 30
    pm.min_spare_servers = 20
    pm.max_spare_servers = 60
    pm.max_requests = 2000
    request_terminate_timeout = 30
    request_slowlog_timeout = 5
    slowlog = /var/log/php-fpm/slow.log
    php_admin_value[memory_limit] = 128M
    pm.status_path = /status
    listen.backlog = 2048
    

• 落地步骤
  • 备份原配置，按“基线测量→计算→示例取值”修改；
  • 平滑重载：systemctl reload php-fpm（或 restart）；
  • 观察free -m、top/htop、FPM status与业务错误（如 502/504）变化，逐步微调。

四 常见误区与代码侧优化

• 误区一：把pm.max_children设得过大，导致内存耗尽/频繁 Swap；应按“可用内存 / 单进程 RSS”计算并留足余量。
• 误区二：忽视pm.max_requests，长时运行后进程 RSS 逐步上升；设置500–5000的回收阈值可显著缓解。
• 误区三：只加进程不查根因；应启用slowlog、监控listen queue与max children reached，判断是“不够用”还是“慢/泄漏”。
• 误区四：静态/动态模式混用不当；内存紧张优先dynamic/ondemand，稳定高并发且内存充足可用static。
• 代码与架构侧优化（减少每个请求的 RSS 与耗时）
  • 优化 SQL 与索引、引入Redis/Memcached缓存、减少阻塞 I/O；
  • 排查第三方库/扩展的内存与性能问题；
  • 合理设置max_execution_time与 FPM 超时，避免长请求拖垮进程池；
  • 开启并分析slowlog，持续优化热点路径与循环。