PHP-FPM 被 OOM Killer 干掉？从定位到防御的实战指南

前几天一个朋友半夜找我，说线上 PHP 项目突然大面积报错，php-fpm 进程像是被什么东西一下子全干掉了，业务直接雪崩。他第一反应是看了 PHP 错误日志，干干净净；看了 nginx 日志，一堆 502；再用 kill -9 去杀残留进程，发现居然“杀不死”——进程明明还在，就是响应不了。我让他敲了一句 dmesg | grep -i oom，结果里面躺着一条内核日志：Out of memory: Killed process 12345 (php-fpm)。不用猜，这就是 OOM Killer 干的。

先说一个很多人踩过的误区：kill -9 杀不死的进程，往往不是它真的“杀不死”，而是进程早就处于不可中断的 D 状态（比如卡在内核 IO 等待上），或者它压根就是个已经死掉但没被回收的僵尸进程。而 PHP-FPM 进程被 OOM Killer 干掉时，表面上像“被杀死了”，实际上系统在内存耗尽时主动选择了它作为牺牲品。这类问题在 PHP 项目中特别常见，尤其是用了 ThinkPHP 3.2.3 这种老框架、一个 php-fpm 进程动辄吃几百 MB 内存、又没有做任何防护措施的场景。这篇我就把 OOM Killer 的前前后后、怎么排查、怎么预防，一次讲透。

1. 先别急着改代码，确认是不是 OOM Killer 干的

很多 PHP 开发遇到进程被“神秘杀死”，第一反应是查业务日志、开 xdebug、怀疑死锁、怀疑 Redis 连接池。这些方向不能说错，但效率太低了。正确的操作顺序是先排除操作系统层面的问题，因为如果是 OOM Killer 导致的，业务代码怎么看都不会有答案。

1.1 三个命令快速定位真凶

判断一个 PHP 进程是不是被 OOM Killer 杀掉的，其实非常快，三分钟以内就能确认：

bash复制# 查看内核日志，OOM 记录一般在这里
dmesg -T | grep -i -E "killed process|out of memory|oom"

# 或者看系统日志
journalctl -k --since "1 hour ago" | grep -i -E "oom|killed process"

# 查看当前内存压力
free -h

如果输出里有类似这样的内容：

code复制Out of memory: Killed process 24680 (php-fpm) total-vm:1856304kB, anon-rss:402312kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:968kB oom_score_adj:0

那基本就实锤了：php-fpm 进程是被内核内存管理机制主动终止的。重点看 total-vm 和 anon-rss 两个字段，前者是进程占用的虚拟内存总量，后者是实际驻留在物理内存中的匿名页大小。我见过很多次 php-fpm 的 anon-rss 单个进程就超过 400MB 的情况，你想想，如果 pm.max_children 配了 50，光 php-fpm 就能吃掉 20GB 内存，物理机稍微小一点必然触发 OOM。

1.2 为什么它选择杀 php-fpm 而不是别的进程

这里得介绍一下 Linux 内核的“选人机制”。系统内存不足时，内核会遍历所有进程，给每个进程打一个 oom_score 分数，分数越高越容易被杀。这个分数的核心组成部分是进程占用的物理内存量，占用越多分越高。同时内核也允许管理员通过 oom_score_adj 来手动调分，范围是 -1000 到 1000，数值越小越不容易被杀。

php-fpm 之所以常常成为 OOM Killer 的目标，核心原因有三点：

• 一个 php-fpm worker 进程的内存占用峰值经常能到 200MB ~ 500MB，特别是装了各种扩展、用了老框架、没有配 OPcache 的情况下，这种进程一眼看过去就是“内存大户”。
• php-fpm 主进程 fork 出的 worker 通常数量很多，几十个 worker 加起来非常可观。
• 很多进程（比如 nginx、Redis、MySQL）要么内存占用相对稳定，要么通过配置限制了最大内存，而 PHP 的 memory_limit 限制的是每个进程的用户态内存，并不等于进程总内存占用，扩展、堆外内存、PHP 解释器本身的开销都不完全受它约束。

换句话说，当内存真正耗尽那一刻，内核“挑软柿子捏”，而 php-fpm 恰好是最软的那个柿子。理解了这一点，你才会明白：解决 OOM 不能只靠调 memory_limit，那是治标不治本。

2. PHP-FPM 层配置：这是第一道防线

如果确认是 OOM Killer 干的，而且你的场景是经典的 PHP-FPM + Nginx 架构，那么第一个要优化的就是 php-fpm 进程管理配置。很多人把 php-fpm.conf 里的 pm、pm.max_children 当成“填了就行”的参数，实际上这些参数直接决定了系统内存的安全水位。

2.1 动态模式和静态模式怎么选

php-fpm 的进程管理模式有三种：static、dynamic、ondemand。我见过不少生产环境直接用默认的 dynamic，但 dynamic 在流量波动大的场景下有一个隐患：它会根据 pm.max_spare_servers 自动预留空闲进程，流量高峰时疯狂 fork 新进程释放请求，高峰过去之后进程回收又比较慢，导致高峰期内存瞬间冲高。

我的经验是：

• 如果服务器内存非常紧张、流量相对稳定，直接用 static，把进程数钉死在一个安全值，宁可在高峰期让请求排队也不触发 OOM。
• 如果流量波动大、希望弹性伸缩，用 dynamic，但必须把 pm.max_children 设置成一个“内存安全上限”，而不是按理想并发来算。
• ondemand 适合内存极小（如 1GB）的小机器，平时不 fork 进程，来了请求再拉起。缺点是请求到来时会有进程创建的开销，偶尔会有短暂的延迟尖峰。

2.2 max_children 的计算方法

pm.max_children 到底该设多少？公式很简单：

code复制max_children = 可用内存 / 单个 php-fpm 进程的平均内存占用

关键是你得先知道“单个 php-fpm 进程的平均内存占用”是多少。我建议你在业务高峰时段执行下面的命令统计：

bash复制ps -eo pid,ppid,rss,cmd | awk '$2 == 1 || $0 ~ /php-fpm/ {print $0}'
ps --no-headers -o rss -C php-fpm | awk '{sum += $1; count++} END {if (count > 0) print "avg_rss_kb=" sum/count ", count=" count}'

或者简单点：

bash复制ps aux | grep php-fpm | grep -v grep | awk '{sum+=$6; n++} END {print "avg RSS(MB):", sum/n/1024, "count:", n}'

假设统计结果是平均每个 php-fpm 进程占用 180MB，服务器上留给 PHP 的内存是 8GB，那 max_children = 8 * 1024 / 180 ≈ 45。注意这里要留 20% 的余量给系统缓存、临时内存峰值，所以我一般会再打八折，取 36 左右。这个数比很多同学拍脑袋设的 100、200 要小得多，但这才是安全值。

2.3 另外几个容易忽略的参数

• pm.max_requests：我强烈建议设置。它表示一个 worker 处理完多少次请求后自动重启。PHP 这种长驻进程跑久了，内存碎片和潜在泄漏会越积越多。设成 500 或 1000 能让 worker 自动“轮换”，把内存释放回系统。
• request_terminate_timeout：之前有个项目就是 curl 请求第三方接口，对方不响应，PHP 进程全部卡在等待上，内存没涨但进程池被打满，间接导致进程堆积、内存飙升。设一个合理的超时（比如 30s），能避免 worker 被长时间占用。
• listen.backlog：在高并发下，如果这个值太小，nginx 转发给 php-fpm 的连接会排队溢出，表现为 502 和连接拒绝，很多人误以为又是内存问题。

下面是一份我常用的 php-fpm 池配置模板，可以在 4 核 8G 的机器上直接改着用：

ini复制[www]
user = www-data
group = www-data

pm = dynamic
pm.max_children = 40
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 15
pm.max_requests = 1000

request_terminate_timeout = 60
listen.backlog = 1024

强调一下：这个配置的核心思路是“限制住峰值内存”，而不是“追求最大并发”。PHP-FPM 的并发能力本来就受限于内存，强行拉高 max_children，一旦内存顶不住，内核会用最粗暴的方式帮你“降并发”——把整个 fpm 池子干掉。

3. 代码和扩展层面的内存优化

配置文件调完了，只能解决“进程太多了”的问题。但如果单个 PHP 进程本身就特别吃内存，配置再怎么调都是杯水车薪。所以第二步要回到代码和扩展层面，把“单进程内存占用”降下来。

3.1 别再把 memory_limit 当摆设

很多 ThinkPHP 老项目里，开发者习惯把 memory_limit 设成 256M 甚至 512M，觉得“反正服务器内存大”。但你要明白，memory_limit 只是 PHP 进程用户态内存的上限，是“最大值”而不是“典型值”。如果一个接口平均要跑 200MB，那这个 memory_limit 实际上在掩护内存浪费，而不是在保护系统。

我见过最典型的一段代码是：

php复制$allRows = Db::name('orders')->select();  // 一次性查出全表
foreach ($allRows as $row) {
    // 逐行处理
}

一张表几十万行，一次性 select() 出来，PHP 内存立刻飙到几百 MB。这种操作在开发环境跑没问题，上线后就是 OOM 的头号诱因。正确做法是使用 chunk 方法分批处理，或者用游标：

php复制// 每次只取 1000 条处理
Db::name('orders')->chunk(1000, function ($orders) {
    foreach ($orders as $order) {
        // 逐条处理
    }
});

还有一个坑是循环里不断拼接字符串或数组，却忘了释放中间变量。PHP 的垃圾回收机制虽然能处理循环引用，但对于大型数组，只要还存在引用，内存就不会释放。比如在循环里把处理结果塞进一个大数组，最后统一 json_encode，这个数组就是内存杀手。

3.2 排查 PHP 扩展的静态内存开销

PHP 加载的每个扩展都会占用内存，尤其是一些“重量级”扩展。之前我排查过一个项目，发现单个 php-fpm 进程空载就占 150MB，后来逐个禁用扩展测试，定位到问题出在一个早期的第三方加密扩展上，它会在每次请求初始化时加载一套巨大的密钥表。把那个扩展换成新版本后，空载内存直接降到 60MB。

快速对比方法：

bash复制# 查看当前 PHP 加载了哪些扩展
php -m

# 查看单个扩展的内存占用，可以通过逐个禁用后重启 php-fpm 观察

如果你用 OPcache，记得开启 opcache.memory_consumption 并设置合理值（比如 128M），同时开启 opcache.validate_timestamps=0（生产环境）。OPcache 的好处不止是加速，它还能避免 PHP 文件重复编译带来的内存碎片和 CPU 开销。对 ThinkPHP 这种文件数量多的框架，收益尤其明显。

3.3 任务型脚本的“分块 + 限流”思路

除了 php-fpm 常驻进程，PHP 还经常用来跑 CLI 脚本，比如队列消费者、定时任务。这类脚本一旦内存失控，同样会被 OOM Killer 清理。而且 CLI 模式下的 PHP 进程往往比 fpm worker 更“肥”，因为很多框架会加载完整运行环境。

我建议所有跑长任务的 PHP CLI 脚本都遵循这几个原则：

• 循环里处理完一批数据后，显式 unset 大变量，并用 gc_collect_cycles() 触发一次垃圾回收。
• 如果任务量很大，内部再分批次，比如每处理 5000 条就记录进度并短暂 sleep(1)，让内存缓存有机会释放。
• 通过 memory_get_usage(true) 在关键节点打印内存占用，观察是否存在持续上涨的趋势。

另外，像 Workerman 这种常驻内存的 PHP 框架，特别容易因为个别协程或回调里持有大对象导致内存只增不减，最终触发 OOM。处理方法是定期重启 worker，或者在框架层做连接池和内存监控。如果你线上就是 Workerman 被 OOM 杀掉，建议不要在 worker 里保存大的缓存数组，改用 Redis 这类外部存储。

4. 系统和内核层面：给 PHP 装上“安全气囊”

配置层和代码层都优化完了，内存压力依然可能在某些极端场景下爆掉，比如流量突增、Redis 缓存穿透、MySQL 慢查询堆积。这时候我们需要在系统和内核层面再兜一层底，确保即使发生内存紧张，OOM Killer 也不会优先选中 PHP 关键进程。

4.1 swap 与 swappiness：给内存“回血”的时间

很多人一听到 swap 就觉得“性能不行”，但在内存告急的场景下，swap 是一道非常重要的缓冲。Linux 的内存回收是异步的，当物理内存不足时，内核需要把一些内存页换到磁盘上或直接回收。如果没有 swap，内核只能立刻执行 OOM Killer；有 swap 的话，内核可以先把不常用的内存页换出去，让 PHP 进程有喘息时间。

我见过一些云厂商的默认镜像直接不配 swap，导致内存只要一紧张就杀进程。建议至少配置 2GB 或内存大小 50% 的 swap：

bash复制# 创建 2G 的 swap 文件
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# 设置开机自动挂载
echo '/swapfile none swap sw 0 0' >> /etc/fstab

同时调整 swappiness 参数，默认值通常是 60，意思是内核会积极地使用 swap。对 PHP 项目，我一般建议设成 10 左右，既保证内存紧张时能及时换出，又不至于让频繁访问的代码段跑到磁盘上去：

bash复制sysctl vm.swappiness=10
echo 'vm.swappiness=10' >> /etc/sysctl.conf

4.2 用 oom_score_adj 保护关键进程

这个参数是内核提供给运维人员的“保命开关”。前面说了，oom_score_adj 范围是 -1000 到 1000，数值越低越不容易被杀。对于 php-fpm 主进程（PID 通常是 1 或者 master），我们可以给它设置一个比较低的分数，让 OOM Killer 优先杀 worker 而不是整个 fpm 池。

实操方式有几种。在 systemd 管理的服务里，直接写在 service 文件里：

ini复制[Service]
OOMScoreAdjust=-500

如果 php-fpm 是通过 init.d 或 Docker 启动的，可以在启动脚本里设置：

bash复制# 找到 php-fpm master 进程 PID
pgrep -f "php-fpm: master" | xargs -I {} sh -c 'echo -500 > /proc/{}/oom_score_adj'

注意：不建议把 php-fpm master 设成 -1000，因为那意味着“绝对不可杀”，一旦内存彻底耗尽，内核可能转而杀掉更重要的进程，比如 sshd 或者 MySQL，反而更麻烦。设成 -500 左右比较合理，让内核优先杀 worker。不过说实话，如果你走到了需要调 oom_score_adj 这一步，说明前期的配置优化还没做到位，这只是最后一层保险。

4.3 overcommit 和内存上限的其他兜底手段

Linux 内核参数里还有一个 vm.overcommit_memory，它控制内核是否允许进程申请超过物理内存的内存。默认值 0 表示“启发式分配”，即内核自己判断是否该允许申请。有些高并发服务会把 PHP 进程的虚拟内存申请得很大，但实际用不了那么多，这时启发式判断可能失灵，导致内存假性耗尽。

如果你对服务器的内存分配有严格把握，可以设为 2，表示“不允许超过物理内存 + swap 总量”的内存申请。但要注意：这个设置对某些依赖内存映射的应用（比如 Java、MySQL 的 buffer pool）可能不友好，自己评估后再改。

bash复制sysctl vm.overcommit_memory=2
vm.overcommit_ratio=80   # 允许使用物理内存 + swap 的 80%

另外，如果你的 PHP 项目跑在 Docker 容器里，一定要给容器设置内存限额：

bash复制# 限制容器最大使用 1G 内存
docker run -d --name my-php-app -m 1g --memory-swap 1g my-php-image

或者在 docker-compose.yml 里写：

yaml复制services:
  php:
    image: my-php-image
    mem_limit: 1g
    memswap_limit: 1g

容器设置内存上限后，当容器内进程内存超过阈值，内核会优先在容器维度处理，而不是直接杀掉物理宿主机上的其它进程。这是很多跑着 ThinkPHP 老项目的同学忽略的一点：宿主机内存明明有 16G，但 10 个容器各自吃内存，加在一起瞬间打爆。

5. 实战案例复盘：三次典型的 PHP OOM 事故

理论讲再多，不如看几个真实案例。下面这三个案例是我在实际项目里遇到并亲自排查过的，每个都对应一种典型原因，你可以对照自己的情况看看属于哪一类。

5.1 案例一：ThinkPHP 3.2.3 老项目，高峰期 fpm 全部阵亡

现象：线上是一个 ThinkPHP 3.2.3 写的商城后台，每天 10 点到 11 点流量高峰时，nginx 502 报错飙升，php-fpm 进程几乎全部消失。

排查过程：先看 dmesg，确认是 OOM Killer 杀掉的。再查 free -h，发现物理内存 8G，而 php-fpm 进程数在高峰期超过 100 个，单进程平均 RSS 有 250MB，算下来光 php-fpm 就占 25G，物理内存早被吃穿了。查 PHP 日志发现框架层日志记录了部分慢查询，但没有报错。

解决思路：把 pm.max_children 从 100 改为 32，pm.max_requests 设为 1000，同时在代码层面把两处一次性读取全表数据的查询改成 chunk() 分块处理，最后配置了 2G swap 做缓冲。调整之后，高峰期内存占用稳定在 6G 以内，OOM 不再出现。

这个案例的典型性在于：老框架 + 未优化的 SQL + 盲目高并发配置，是 PHP OOM 最常见的组合。ThinkPHP 3.2.3 本身不是问题，问题在于它会把很多数据都加载到内存里，比如自动加载的模型文件、配置缓存、路由匹配等，一旦并发上来，内存就被放大了。

5.2 案例二：Workerman 常驻进程内存持续上涨，一周后被杀

现象：一个基于 Workerman 做的 WebSocket 推送服务，运行一段时间后内存占用不断攀升，每三四天进程就会被 OOM Killer 干掉一次，客户端大量掉线。

排查过程：用 top 实时观察单个 worker 的内存变化，发现每处理一条消息，RSS 就会增长几十 KB 且不回落。结合代码审查，定位到问题在全局数组缓存了每个客户端的连接对象，连接断开时只做了 unset，但数组的 key 没有清理，导致每个连接断开后只是把对象标记为可回收，而数组本身没有释放。

解决思路：改成在连接关闭时显式删除数组元素，并使用 gc_collect_cycles() 强制回收；同时给 Workerman 的 master 进程设置了 oom_score_adj=-500，并配置了每日凌晨自动平滑重启服务，作为兜底。

这个案例的教训是：常驻型 PHP 服务对内存泄漏的容忍度极低。普通 fpm 进程是“请求结束即释放”，就算有泄漏也是在单个请求内，影响有限；但 Workerman 这种进程是 7x24 小时不退出的，任何微小的内存泄漏都会在几天内累积成灾难。所以跑常驻 PHP 服务的朋友，务必在你的运维脚本里加上“定期查看进程 RSS 趋势”的监控，并且强制设置 pm.max_requests 或定时重启策略。

5.3 案例三：Docker 容器内 PHP 频繁被杀，宿主机内存充裕

现象：一个部署在 Docker 里的 PHP 项目，跑着跑着容器就退了，docker inspect 看状态是 OOMKilled，但宿主机内存明明还很空。

排查过程：一开始我也很困惑，后来查了 Docker 的配置才发现，不是宿主机内存不够，而是容器自己设置的内存限额太小。这个项目在创建容器时用了 -m 512m，而一个 PHP-FPM 容器跑着至少 10 个 worker，每个 worker 平均 80MB，再加 OPcache 和框架常驻内存，跑个一两天就触顶。

解决思路：调整容器内存限额到 1.5G，同时压减容器内的 pm.max_children 到 8，并做一个健康检查——如果容器内存使用率超过 85%，就输出告警。再配合 --memory-swap=1.5g 确保容器无法用 swap 逃避限额。调整后稳定运行三个月没有再出现 OOMKilled。

这个案例的启示是：先看容器限额，再看宿主机内存。不少人在 Docker 部署时随手写一个 -m 参数，以为只是“限制上限”，实际上这个值要是设置得比应用实际需求还低，就会变成“主动谋杀”。容器内的 PHP 项目，最好结合前面说的内存统计方法，为容器预留 1.5 到 2 倍的平均内存作为限额。

6. 常见问题与排查技巧实录

最后整理一份我经常在排查 PHP OOM 时用到的“速查表”，以及一些常规文档里不会写的小技巧。

6.1 问题速查表

6.2 一个非常实用的内核排查技巧

很多人不知道内核在杀进程之前，其实会在系统日志里详细记录当时的“内存分布”。dmesg 里的 OOM 日志会把每个进程的内存占用列成一张表，但日志可能被环形缓冲冲掉。所以建议在内存紧张问题出现后立刻执行：

bash复制dmesg -T | tail -n 200 > /tmp/oom_debug.log
journalctl -k --since "30 min ago" > /tmp/kernel_debug.log

另外，如果系统内存频繁告急但又不至于触发 OOM，可以用这个命令看看当前 Linux 的内存回收压力：

bash复制cat /proc/vmstat | grep -E "pgscan|pgsteal|kswapd"

其中 kswapd 开头的字段如果增长很快，说明内存回收线程在频繁运作，是内存即将告急的前兆。这些信息可以作为监控项的参考。

6.3 关于“kill -9 杀不死进程”的真相

热搜词里有“kill -9 杀不死进程”，这里多写两句。用 kill -9 杀 php-fpm 时，如果发现杀不死，通常有两种情况：

• 进程处于不可中断的 D 状态，说明它在等待内核 IO 完成，此时任何信号都无效，只能等 IO 恢复或者重启机器。
• 你杀的是 php-fpm: pool www 的 worker，但 master 进程会立刻 fork 出新 worker 顶上，看起来就像“杀不死”。这时应该杀 master 进程而不是 worker。

bash复制# 杀掉 php-fpm master 进程
kill -QUIT <master_pid>

# 如果 master 也杀不掉，再确认状态
ps -o pid,stat,cmd -p <master_pid>

说实话，如果追求“彻底杀掉”，更稳妥的做法是：

bash复制systemctl stop php-fpm

或者直接停止整个服务，而不是手动 kill。kill -9 只适合处理个别失控 worker，不适合作为日常停止服务的手段。

7. 监控与主动防御：别等 OOM 了再救火

OOM Killer 是内核的最后手段，能用上它说明前面的防护措施都失效了。与其每次都被动救火，不如提前把监控和主动防御搭起来。这部分是很多小团队最容易忽略的，但恰恰是投入产出比最高的一环。

7.1 内存监控指标怎么设

我建议至少监控三层的指标：

• 宿主机层：整体内存使用率、swap 使用率、pgscan/pgsteal 的速率。
• 进程层：php-fpm 进程池的活动进程数、空闲进程数、单个 worker 的平均 RSS、最大 RSS。
• 应用层：PHP-FPM 的 listen 队列长度（可以通过 php-fpm.status 暴露的指标获取）。

对于 PHP-FPM，开启状态页能拿到很多关键数据。在 pool 配置里加：

ini复制pm.status_path = /phpfpm_status

然后在 nginx 里把 /phpfpm_status 转发给 fpm，用 curl 访问就能看到：

bash复制curl http://127.0.0.1/phpfpm_status?full

返回的数据里重点看 accepted conn、listen queue、max active processes、max children reached。如果 max children reached 为 1，说明曾经达到过 max_children 上限，这是一个非常危险的信号，意味着系统在那一刻已经“无进程可用”了，内存和进程池都在崩溃边缘。这个指标应该做成告警项，阈值设为 1（只要发生就告警）。

7.2 自动重启策略到底该不该用

很多团队为了省事，会写一个 cron 脚本定期检测 php-fpm 状态，发现内存高就重启。这种做法有用，但只能作为兜底，不能替代根因分析。因为如果每次都是因为代码泄漏或者配置不合理才导致内存高，那把自动重启加上，只是把问题从“进程被杀”变成“进程每天定时被杀”，业务方感受到的依然是不稳定。

我个人的建议是：

• 在还没定位根因之前，可以临时用自动重启保命，但每次重启都要保留现场数据（进程数量、内存、请求数），方便事后分析。
• 定位到根因后，自动重启的触发条件应该收紧，比如内存使用率持续 5 分钟超过 90% 才重启，避免频繁误杀正常服务。
• 如果已经用了 pm.max_requests，重启其实是 php-fpm 自己完成的，不需要额外脚本干预。

7.3 从被动救火走向主动规划：给一台服务器留多少内存才算合理

很多同学会问，一台服务器到底要配多少内存才安全？这个问题没有标准答案，但我可以给一个经验公式：

code复制需要内存 = PHP-FPM 进程数 * 单进程平均内存 + 业务缓存预留 + 系统预留

举例来说：一台 4 核 8G 的机器，跑一个 ThinkPHP 项目，平均每个 php-fpm 进程 180MB，设 max_children = 30，那 PHP 这边就占了 5.4G。再给 MySQL 留 2G（如果是同机部署），系统本身占 1G，加起来已经 8.4G，明显超标。所以这种情况下要么把 max_children 降到 24，要么把 MySQL 拆到独立机器，要么加内存到 16G。

定期做一次内存压力测试也很有用，比如用 ab 或 wrk 打一波并发，观察内存曲线，就能在线上出问题之前发现瓶颈。这一步比写什么监控都更能让你心里有底。

8. 最后分享一个排查小技巧

排查 PHP OOM 问题的时候，我习惯在第一现场保留一套完整的内存快照。具体做法是拿到 dmesg 的 OOM 记录后，立刻把当时的进程内存列表打出来：

bash复制ps -eo pid,ppid,rss,vsz,cmd --sort=-rss | head -30

然后把这 30 行存成文件，并和正常的业务流量做对比。很多时候你不需要立刻修改配置，数据拿全了再动手，可以避免“调了这个参数又引发另一个问题”的连锁反应。

另外，如果项目里用了 ThinkPHP 这类框架，建议把框架的调试日志打开，特别是内存占用最高的那几次请求，把 URL、参数、执行时间记录下来。我之前有一次就是靠框架日志里内存占用最高的 10 个请求，定位到了一处 Excel 导出的接口——那个接口会把所有数据一次性加载到内存再做渲染，单次请求内存超过 600MB，接口平时没人用，但只要有人点一次，整个池子就会掀起一阵涟漪。

这是典型的“低频高危”请求，也是 OOM 排查里最容易忽视的一类问题。低并发不代表低风险，内存峰值才是核心。