centos下php-fpm内存占用高怎么解决

CentOS 下 PHP-FPM 内存占用高的排查与优化

一、快速定位占用来源

遇到 PHP-FPM 把内存吃满的情况，先别急着调参数，得搞清楚到底是“人太多了”还是“每个人太能吃了”。几个命令就能把问题摸清楚。

• 先跑个 free -m，看看物理内存还剩多少，交换分区是不是已经开始高频换页了——如果 OOM Killer 已经在杀进程，那说明情况已经很紧急了。
• 接着用 top 然后按 Shift+M 按内存排序，或者直接 ps -eo pid,ppid,cmd,%mem,rss --sort=-%mem | head，找出内存占用最高的那几个 php-fpm 进程，看看是不是有个别进程异常膨胀。
• 再统计一下进程总数：pstree | grep php-fpm 或者 ps aux | grep php-fpm | wc -l，如果数量已经远远超出你的预期，那「进程过多」就是主因。
• 想估算单进程的常驻内存（RSS），用 ps -o pid,rss,cmd -C php-fpm，能看到每个子进程吃了多少 KB。这个值后面算 max_children 时要用。
• 别忘了翻日志：/var/log/php-fpm.log 以及 pool 的慢日志（比如 www.log 的 slow 段），看有没有异常请求、死循环或者慢 SQL 把进程拖住了。
• 如果你用的是 Nginx，还要核对一下 fastcgi 的超时和缓冲设置，避免上游阻塞导致 php-fpm 进程长时间不释放。

做完这几步，心里就有底了——到底是进程数量太多，还是单进程内存泄漏或膨胀，后续的优化方向也就清楚了。

二、核心优化步骤

定位到问题之后，下面是几招最直接的优化手段，组合起来用效果立竿见影。

• 选对进程管理模式
  小内存或者负载波动明显的场景，优先用 dynamic，进程数按需伸缩，省内存。
  大内存、追求高稳定性，可以考虑 static，省去频繁创建销毁的开销。
  内存极其紧张、并发很低的场景，ondemand 也可以试试，有请求才 fork 子进程，但首次响应会略慢半拍。
• 算准 max_children
  估算公式很简单：max_children ≈ 可用内存 / 单个子进程常驻内存（RSS）。
  举例来说，1GB 内存的 VPS，单进程 RSS 如果 50MB 左右，那 max_children 大约就是 20。实际数值得看你项目里用的 PHP 扩展和业务代码来微调。
• 动态模式的配套参数
  pm.max_spare_servers 建议设为 max_children 的 60%–80%，既能应对突发流量，又不至于闲置太多进程。
  还是拿 1GB 内存、单进程 50MB 估算：max_children 设 20，那么 max_spare_servers 就可以设在 12–16 之间。
• 控制生命周期，防止泄漏积累
  设置 pm.max_requests（比如 500–5000），让子进程处理完一定数量的请求后自动回收，释放可能的内存碎片和泄漏。
• 给脚本戴上“紧箍咒”
  在 pool 配置里加一行 php_admin_value[memory_limit]，比如 32M、64M 或 128M，防止单个脚本把内存全吃掉。
• 生效与回滚
  改完配置先用 systemctl reload php-fpm 观察，稳定了再重启。变更前务必备份原配置。这一套组合拳能同时解决「进程过多」和「单进程吃内存」两类根因。

三、配置示例

下面给两个典型配置，你可以根据自己的实测 RSS 和业务峰值微调。

示例 A（保守型，适合 1GB 内存，动态模式）

[www]
pm = dynamic
pm.max_children = 20
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 12
pm.max_requests = 1000
php_admin_value[memory_limit] = 64M

示例 B（稳定型，适合 8C/16GB 内存，静态模式）

[www]
pm = static
pm.max_children = 20
pm.max_requests = 2000
php_admin_value[memory_limit] = 128M

说明：示例 A 中 max_spare_servers 取了 max_children 的 60%（12）。示例 B 用 static 固定 20 个进程，适合高并发且内存宽裕的场景——当然，具体数值一定要结合你的 RSS 实测和业务峰值来调整。

四、应用侧优化与长期治理

调完了 PHP-FPM 配置，其实还有一大半工作要做。从应用层面减负，才能从根本上降低每个请求的内存峰值和并发压力。

• 给代码和依赖“瘦身”
  减少重型扩展（比如 imagick、xhprof、grpc）的全局加载，只在需要的路由里初始化。避免在请求中反复加载大文件。
• 缓存与分页
  生产环境务必开启 OPcache。列表页、搜索页要做好分页和数据缓存，单次请求的内存消耗和响应时间都能降下来。
• 队列化解耦
  邮件发送、数据导入、图片处理这些耗时操作，丢到消息队列或后台任务里异步执行，别让 FPM 进程在那干等。
• 数据库与 I/O 优化
  慢查询加索引、批量提交、限制单次请求处理的数据量——这些老生常谈的事，往往是内存占用的隐性杀手。
• 监控与告警
  持续跟踪 RSS、进程数、max_requests 回收次数、慢日志。设置内存阈值告警，一旦异常版本上线能及时回滚。
• 变更流程
  先在测试环境用 ab、wrk 或 siege 压一把，记录峰值 RSS 和 95 分位响应时间，确认没问题再推生产。稳扎稳打，才能长治久安。

通过“代码减负 + 缓存 + 异步 + 限流”的组合，每个请求的峰值内存和并发压力都能得到根本性改善。