linux内存告警四特征：1. free -m显示available≈0但buff/cache很高；2. dmesg出现“or sacrifice child”日志且Badness得分＞800；3. vmstat中si/so持续非零、pgmajfault飙升；4. 容器内memory.usage_in_bytes逼近limit且failcnt递增，limit设为-1可能因溢出误触发OOM。
系统响应明显变慢，free -m 显示 available 接近 0 但 buff/cache 很高
这不是“真缺内存”，而是 Linux 把空闲内存全拿去缓存文件了。一旦新进程要内存，内核得先回收缓存；如果回收不过来，就直奔 OOM。此时 free -m 看起来像“只剩 50MB 可用”，但 buff/cache 占了 8GB——这是典型预警信号，不是故障已发生，而是缓冲区快压不住了。
dmesg -T | grep -i "killed process" 开始出现，但还没真正 kill 进程
OOM Killer 在真正动手前会试探性记录。你可能先看到类似这样的日志：
Out of memory: Kill process 12345 (java) score 892 or sacrifice child注意关键词：or sacrifice child 表示内核还在权衡要不要杀子进程；score 892 是 Badness 得分（越高越危险），超过 800 就该警觉了。这个阶段系统还能跑，但已经进入“临界滑坡”——只要再有一个大内存申请（比如日志轮转、定时任务、数据库查询），就会触发真实 kill。
频繁触发 pgmajfault，vmstat 1 中 si/so 持续非零
用 vmstat 1 观察时，如果 si（swap in）和 so（swap out）列持续大于 0，说明物理内存已严重不足，内核正疯狂把进程页换入换出。同时 pgmajfault（重大缺页）数值飙升，意味着进程不断访问尚未映射到物理内存的虚拟地址，被迫等内核现场分配页——这正是 OOM 前最耗时的卡顿来源。
- 正常负载下
si/so应长期为 0； - 哪怕有 Swap，
so > 100 KB/s持续 30 秒以上，基本等于在给 OOM 倒计时； - 此时
top里 %MEM 排名靠前的进程未必是元凶——短生命周期+高内存申请速率的进程（如 python 脚本批量读 csv）更危险，但top看不到它刚启动那几秒的爆发式申请。
容器环境里 docker stats 或 cgroup 内存统计突然跳变
在 Docker/K8s 环境中，OOM 往往先发生在单个容器内（cgroup memory limit 被突破），而非宿主机全局。此时宿主机 free 可能还很宽裕，但容器内 cat /sys/fs/cgroup/memory/memory.usage_in_bytes 会逼近 memory.limit_in_bytes，且 memory.failcnt 开始递增。kubernetes 的 Events 里会出现 OOMKilled 状态，但比宿主机级 OOM 日志晚几秒——因为 cgroup 层的 OOM 是独立触发的，不经过宿主机 oom_killer 流程。
最容易被忽略的一点：memory.limit_in_bytes 设为 -1（不限制）≠ 安全。某些旧版 runC 或内核版本下，-1 实际会被解释为极大值（如 2^63），导致 cgroup 内存统计溢出、误判为超限，进而提前触发容器级 OOM。务必确认实际生效值：cat /sys/fs/cgroup/memory/memory.limit_in_bytes 返回的是数字，不是 -1。