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 前最耗时的卡顿来源。
