VPS频繁被OOM杀进程怎么办？用memory.events定位cgroup内存上限
服务突然退出、systemd不断重启，日志里出现“Out of memory”或“Killed”，不一定是整台VPS的物理内存都用光了。Linux可能在cgroup内存上限、容器限制或整机回收压力下触发OOM。先区分作用域，才能决定是调大限制、减少工作集，还是扩容。
先判断谁被杀
保留最近一次故障前后的日志和服务状态：
journalctl -k -b --no-pager | grep -Ei 'oom|out of memory|killed process'
systemctl status example.service
free -h
cat /proc/pressure/memory内核日志点名某个进程时，记录PID、RSS和时间；如果只有容器日志出现OOM而宿主机仍有可用内存，优先检查容器的cgroup。
用memory.events看限制是否触发
在cgroup v2环境，常见文件包括：
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.events
cat /sys/fs/cgroup/memory.stat | headmemory.events里的high、max、oom和oom_kill是计数器。oom_kill增长，说明该层级确实杀过进程；memory.max显示具体上限。不要把free -h的整机数值直接当成容器可用内存。
| 证据 | 判断 | 处理方向 |
|---|---|---|
| memory.max较小，oom_kill递增 | cgroup上限触发 | 核对服务配额、降低并发或合理提高上限 |
| 整机可用内存持续下降，内核日志点名多个进程 | 整机内存压力 | 减少工作集、增加安全余量或扩容 |
| RSS稳定但缓存回收频繁 | 工作集与文件缓存竞争 | 检查缓存策略和I/O写入模式 |
| 只在启动或批处理峰值发生 | 瞬时峰值超限 | 错峰、分批、设置并发上限 |
不要先盲目加Swap
Swap能缓冲部分匿名页压力，但不能替代cgroup上限，也无法解决持续的内存泄漏。先查看服务的RSS/PSS、并发数、缓存和批任务峰值，再决定是否配置Swap。调整前保留快照或配置备份，并确认云盘I/O能力能承受换页。
安全处理步骤
- 记录memory.current、memory.max和memory.events的前后差值；
- 按PID核对服务、子进程和线程的实际内存；
- 为批处理设置并发、队列和单任务上限；
- 只有在工作集合理且业务需要时，才提高cgroup额度；
- 变更后重复同一负载并观察oom_kill是否停止增长。
如果服务由systemd管理，检查MemoryMax、MemoryHigh和重启策略；如果由容器管理，核对部署文件与运行时限制，避免只改宿主机参数却被下一次发布覆盖。
哪些情况需要扩容或回滚
当正常工作集已经接近实例上限、峰值无法通过排队削平，或OOM伴随明显的内存压力和Swap抖动时，扩容比继续调参更稳妥。若调高限制后延迟、换页或费用明显恶化，应按预案回滚，并重新评估应用内存模型。
OOM排查的核心不是“把内存调到最大”，而是找出触发层级、被杀进程和峰值来源。memory.events提供了可复核的计数证据，适合与服务日志和发布记录一起留档。
