一台运行着若干服务的 Debian 服务器，某天发现某个关键进程突然消失了，重启之后过一段时间又没了。翻看系统日志，里面赫然出现一行字：Out of memory: Killed process。这种情况几乎每个运维人员都会碰到，而背后的“凶手”就是 Linux 内核内置的 OOM killer。OOM 是 Out Of Memory 的缩写，当系统物理内存和 swap 交换空间全部耗尽，内核无法再为新的内存请求分配页面时，会调用 OOM killer 强制终止一个或多个进程，释放内存让系统继续运行。这个机制本身是为了避免整个系统因内存耗尽而彻底死机，但它的“随机杀人”行为常常让开发者感到困惑—为什么被杀的是我的进程？有没有办法保护重要服务？本文将深入解析 Debian 系统中 OOM killer 的工作原理、排查方法以及防护策略。
OOM Killer 的选择逻辑与内核参数
OOM killer 并不是毫无章法地随机杀进程，它有一套基于打分的选择机制。每个进程在内核中都有一个 oom_score 值，这个值越高，表示该进程在内存紧张时越应该被优先终止。oom_score 的计算综合考虑了进程当前占用的内存、子进程占用的内存、进程运行时间、进程的 nice 值以及是否被用户显式调整等因素。普通进程的 oom_score 范围通常在 0 到 1000 之间，数值越大越危险。管理员和开发者可以通过查看 /proc 文件系统来获取某个进程的 oom_score，例如查看 PID 为 1234 的进程：
cat /proc/1234/oom_score
输出一个整数，比如 620。这个数值本身没有绝对意义，但在内存耗尽时，内核会遍历所有候选进程，选择 oom_score 最高的那个终止。除了 oom_score，还有一个更常用的调整参数叫做 oom_score_adj，它允许手动对 oom_score 进行微调。oom_score_adj 的取值范围是 -1000 到 1000，它与 oom_score 的关系可以理解为：最终的 oom_score 等于内核原始计算的分数加上 oom_score_adj 的修正值，然后限制在 0 到 1000 之间。如果把某个进程的 oom_score_adj 设置为 -1000，那么这个进程几乎永远不会被 OOM killer 选中，因为它最终的 oom_score 会被压到 0。
Debian 系统默认情况下，systemd 管理的服务、sshd 等关键进程的 oom_score_adj 会被设置为一个较低的负值，以降低被误杀的概率。可以通过以下命令查看所有进程的 oom_score_adj 大致分布：
ps -eo pid,comm,oom_score_adj | sort -k3 -n
如果发现某些应用进程的 oom_score_adj 为 0，而内存占用又特别高，那么它就会成为 OOM killer 的首要目标。理解这个打分机制，是后续排查和防护的基础。
如何确认进程是被 OOM Killer 杀掉的
进程突然退出有很多可能原因：程序自己崩溃、收到 SIGKILL 信号、被 systemd 重启等。要确认是 OOM killer 所为，最直接的方法是查看内核日志。在 Debian 系统上，可以使用 dmesg 命令查看最近的内核环形缓冲区输出。OOM killer 的日志非常典型，通常会包含 Out of memory 字样、被杀进程的名称和 PID、以及当时的内存使用情况。一条完整的日志类似下面这样：
dmesg -T | grep -i "out of memory" [Wed Sep 18 10:22:34 2024] Out of memory: Killed process 2456 (java) total-vm:4194304kB, anon-rss:2048000kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:4096kB oom_score_adj:0
这条日志明确告诉我们，PID 为 2456 的 java 进程被杀了，它占用了大约 2GB 的匿名内存，oom_score_adj 为 0。如果系统使用 systemd-journald 管理日志，还可以用 journalctl 命令按时间段过滤：
journalctl -k --since "10:20" --until "10:25" | grep -i "out of memory"
需要注意的是，dmesg 的输出可能会因为内核日志缓冲区被覆盖而丢失，尤其是内存压力很大的情况下，日志产生量也会很大。如果怀疑进程被 OOM killer 杀掉，但 dmesg 里找不到记录，可以检查 /var/log/syslog 或 /var/log/kern.log，Debian 默认会把内核日志写入这些文件。
除了日志之外，还可以观察被杀进程的特征。OOM killer 发的是 SIGKILL 信号，进程无法捕获和处理，也不会留下 core dump 文件。如果进程的退出码或状态显示为 killed by signal 9，同时在系统日志中发现内存相关告警，基本可以断定是 OOM killer 所为。排查时还要注意，OOM killer 有时会杀掉一个进程组或多个进程，如果发现同一时间多个进程一起消失，也是典型的 OOM 特征。
保护关键进程不被 OOM Killer 杀掉
了解了原理和排查方法之后，下一步就是如何让重要的服务在内存紧张时存活下来。最直接的方式是手动调整 oom_score_adj。比如有一个数据库进程 PID 为 3000，我们希望它尽量不被杀，可以将其设置为 -500 或更低：
echo -500 > /proc/3000/oom_score_adj
或者使用 systemd 的服务单元配置文件来持久化这个设置。在服务单元中加入 OOMScoreAdjust 指令，例如：
[Service] OOMScoreAdjust=-500
这样服务每次由 systemd 启动时都会自动应用该调整，不需要手动 echo。需要注意的是，把 oom_score_adj 设置得越低，意味着这个进程在 OOM 时越安全，但同时也可能导致其他进程被牺牲。如果所有关键进程都被保护起来，最后可能只能杀掉 init 或 systemd 本身，那系统还是会出问题。因此这种做法要谨慎，只对真正重要的进程使用。
另一种思路是从全局内存管理策略入手。内核参数 vm.overcommit_memory 控制内存超额分配行为。默认值 0 表示启发式分配，允许一定程度的超额分配；设置为 1 表示总是允许超额分配，这会大幅增加 OOM killer 触发的概率；设置为 2 表示严格限制分配，不允许超过物理内存和 swap 的一定比例。很多生产环境将 vm.overcommit_memory 设为 2，配合 vm.overcommit_ratio 参数来预留一部分内存给系统关键进程。修改方法：
sysctl -w vm.overcommit_memory=2 # 持久化到 /etc/sysctl.conf echo "vm.overcommit_memory=2" >> /etc/sysctl.conf
不过严格模式也可能导致内存分配失败，一些依赖内存过量分配的应用可能会报错，需要根据实际负载测试。
更精细的控制方式是使用 cgroup 的内存限制。cgroup v2 已经在 Debian 10 及之后的版本成为默认，可以为每个服务或容器设置 memory.max 和 memory.high。当 cgroup 内的内存使用超过 memory.max 时，内核会在该 cgroup 内部触发 OOM killer，只杀掉该 cgroup 内的进程，而不会影响宿主机上的其他服务。这样既能防止单个服务无限制吃内存，又能把 OOM 的影响范围限制在局部。配置一个名为 myapp 的 cgroup 并限制为 1GB 内存的示例：
mkdir /sys/fs/cgroup/myapp echo "1G" > /sys/fs/cgroup/myapp/memory.max echo "$$" > /sys/fs/cgroup/myapp/cgroup.procs
这种方式在现代容器化和微服务环境中尤其推荐，它比手动调整 oom_score_adj 更可控，也更符合资源隔离的理念。
最后还要强调，任何防护手段都无法替代真正的内存优化。OOM killer 只是内存耗尽后的最后防线，频繁触发说明系统内存规划不合理或者应用存在内存泄漏。定期监控内存使用趋势、分析进程的 RSS 增长、优化代码中的缓存策略，才是解决问题的根本。Debian 提供了丰富的监控工具，比如 top、htop、smem、以及 prometheus + node_exporter 等，把这些工具用起来，才能在 OOM 发生之前发现隐患。
Debian Out of memory killer进程被杀内存溢出修改时间：2026-08-23 21:11:05