频繁触发oom killer表明系统持续内存高压，需结合dmesg与系统日志定位时间点、进程pid及cgroup路径，区分全局缺内存或cgroup超限，并用smem、gc日志等分层验证真实内存占用，再通过oom_score_adj等参数合理调控。
频繁触发OOM Killer，说明系统持续处于内存高压状态，不是单次偶然事件。重点不是“杀掉了谁”，而是“为什么总不够用”。日志是起点，但必须结合上下文交叉验证。
看日志：先定位时间点和关键进程
执行以下命令快速抓取线索：
- dmesg -T | grep -i "killed process" —— 带时间戳的原始内核日志，最可靠
- grep -i "out of memory" /var/log/kern.log（Debian/Ubuntu）或 /var/log/messages（RHEL/CentOS）
- 注意日志中三类关键信息：时间戳、被杀进程名与PID、所在cgroup路径（如
cgroup=/mm_test）
分清类型：是全局缺内存，还是cgroup超限？
日志里出现 cgroup= 字样，基本可判定是容器或资源组限制导致，而非整机内存耗尽。常见情况包括：
- 父cgroup内存设为200MB，子进程虽未超限，但父级已满，OOM Killer仍会杀子进程
- 共享内存（shm）占用过高，占满cgroup用户态内存配额的30%以上，也会触发OOM
- NUMA节点隔离：cpuset.mems限定只用某块内存，即使其他节点空闲，该cgroup也会OOM
查进程：别只信free和top的“可用”值
free -h 显示的 available 是估算值，常严重高估真实可用内存。应分层验证：
- 用 smem -s rss 查实际物理内存占用（RSS），比 top 的 %MEM 更准
- 对Java进程，加 -XX:+PrintGCDetails -Xloggc:gc.log，用 gceasy.io 分析GC日志，看是否频繁Full GC但内存不降
- 检查是否存在 DirectByteBuffer 泄漏、静态Map未清理、线程数失控（如Paimon写入开100个bucket线程）
调参数：控制OOM Killer行为，不是禁用它
临时缓解可调整内核参数，但本质是争取排查时间：
- sysctl -w vm.oom_kill_allocating_task=1：让OOM Killer优先杀当前申请失败的进程，避免误杀长时服务
- echo -1000 > /proc/PID/oom_score_adj：对关键进程（如数据库、核心API）设为-1000，禁止被杀（需root）
- 检查 cat /proc/sys/vm/panic_on_oom，确保为0（启用OOM Killer而非直接panic）
