Linux 服务运行一段时间后突然退出，终端只显示一个 Killed，应用日志里却没有明显报错。这种情况不一定是程序主动结束，更常见的是系统内存压力过大，内核为了保住整台服务器而终止某个进程。
我排查过不少网站和容器突然消失的问题，重启服务往往能短暂恢复，但只要内存占用再次冲高，故障还会重复。真正需要确认的是谁触发了 OOM、谁被杀掉，以及内存为什么耗尽。
今天就来讲清楚 OOM Killer 的工作方式、日志查看方法和实际处理思路。
一、OOM Killer到底是什么
当物理内存和可用交换空间不足，内核又无法回收足够内存满足新的分配请求时，可能触发 Out of Memory 处理。为了让系统继续运行，内核会选择一个或多个进程终止并释放内存。
因此 OOM Killer 不是病毒，也不是某个软件名。它是 Linux 在严重内存压力下的保护机制。被杀掉的进程未必就是唯一的问题来源，还要结合整个系统当时的内存使用判断。
容器环境还可能出现 cgroup 范围内的 OOM。宿主机仍有内存，但容器达到自己的内存上限，同样会被终止。
二、怎样确认进程是不是被OOM杀掉
先查内核日志。不同系统可尝试 journalctl -k -g 'oom\|Out of memory\|Killed process' --since today，也可以用 dmesg -T | grep -Ei 'oom|out of memory|killed process'。
日志里常能看到触发时间、被终止的进程、PID、内存占用和 OOM 评分。应用日志突然中断而内核日志出现 Killed process，基本就能确认方向。
Docker 可用 docker inspect 容器名 --format '{{.State.OOMKilled}}' 检查状态。Kubernetes 则常在 Pod 状态中看到 OOMKilled，还要进一步区分容器限制和节点内存压力。
三、为什么内存看起来没有占满也会发生
你在故障后执行 free -h，看到的是进程已经被杀、内存释放后的状态，不是触发前的现场。只靠事后截图很难还原峰值。
Linux 还会把空闲内存用于缓存，这部分多数可以回收，不能把 used 一项直接理解为程序全部占用。更值得关注的是 available、Swap变化、进程 RSS，以及是否持续发生内存回收和换页。
瞬时并发、数据库大查询、PHP或Java进程数量失控、图片处理、构建任务和容器没有限制，都会在几秒内吃掉大量内存。
四、找出真正的内存来源
故障发生时可用 ps aux --sort=-%mem | head 或 top 查看高内存进程。长期问题应使用监控记录峰值，而不是等进程被杀后再看。
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| 单个进程持续增长 | 内存泄漏或任务规模过大 | 查应用版本、日志和请求 |
| 大量相同进程占满 | 并发上限过高 | 限制worker数量 |
| 数据库突然冲高 | 大查询、缓存或连接过多 | 查慢查询和配置 |
| 容器显示OOMKilled | 达到容器内存限制 | 调整限制或降低占用 |
| 整机频繁换页 | 物理内存长期不足 | 减少服务或升级内存 |
不要只盯着被杀进程名称。内核会根据评分选择目标，某个重要服务可能因为占用大而成为牺牲对象，但真正的压力也可能来自其他进程共同叠加。
五、加Swap能不能解决OOM
Swap 能给短时峰值提供缓冲，让系统有机会回收内存或完成任务，但磁盘速度远慢于内存。持续依赖 Swap 会出现明显卡顿，甚至形成高 I/O 和高负载。
小内存 VPS 没有 Swap 时，可以配置适量交换空间作为保护，但它不能替代内存升级。数据库和延迟敏感业务还要结合实际写入量与性能评估。
更有效的处理通常是限制应用并发、给容器设置合理内存、修复泄漏、拆分重任务，并保留足够的系统余量。
六、哪些做法风险比较大
不要为了避免进程被杀就直接禁用 OOM Killer。内存真正耗尽时，整台服务器可能长时间无响应，SSH也进不去。
也不要看到缓存占用就频繁手动清理系统缓存。Linux会按需回收缓存，反复清理可能降低性能，却没有解决应用内存持续增长的问题。
需要保障关键服务时，可以了解 systemd 或容器的资源限制与重启策略，但必须先测好上下限。把一个服务保护得太高，压力可能转移到数据库或系统组件。
七、从配置和监控上预防
至少监控可用内存、Swap、主要进程RSS、容器内存和 OOM 事件。告警阈值要给处理留出时间，不能等 available 接近零才通知。
新项目不要把套餐内存全部分给应用。需要灵活调整配置时，可比较 萤光云 和 LightNode 的升级、快照与计费规则，先用真实业务压测，再决定长期配置。
我更建议保留 20%左右的内存余量，同时限制最容易突增的 worker、容器和数据库连接。具体比例仍要根据业务峰值调整。
常见问题
问：终端显示Killed就一定是OOM吗？
答：不一定，还可能是管理员或程序发送信号，需要结合内核日志确认。
问：OOM Killer会重启服务器吗？
答：通常只终止进程，但严重内存压力可能让系统无响应或触发其他恢复机制。
问：Docker容器OOM后会自动启动吗？
答：取决于容器重启策略，自动重启也不能替代内存问题排查。
问：Swap越大越好吗？
答：不是，Swap主要用于缓冲，持续大量使用会显著降低性能。
问：怎样保留OOM发生前的数据？
答：部署持续监控，并将系统日志发送到独立存储或远程日志服务。
温馨提示
进程突然被杀后，先查内核日志，再看容器限制和历史监控。不要只重启服务，也不要因为当前内存已释放就认定系统正常。
解决 OOM 的核心是控制 内存峰值、并发上限、容器限制和系统余量。Swap与自动重启只能争取恢复时间，不能代替根因处理。
