Linux OOM Killer调优核心是合理配置vm.overcommit_memory、vm.panic_on_oom、vm.oom_kill_allocating_task及/proc/[pid]/oom_score_adj等参数，结合业务场景控制内存分配策略与进程选择倾向，而非简单禁用；推荐数据库等关键服务设overcommit_memory=2、oom_score_adj=-500～-900，并调低swappiness以减少误触发。
Linux 系统中调整 OOM Killer 的触发策略，核心不是“禁用”或“关闭”，而是通过控制内存分配行为、OOM 触发时机和进程选择倾向，让系统在内存紧张时做出更符合业务需求的响应。关键参数集中在 /proc/sys/vm/ 下，需结合业务负载类型（如数据库、Web 服务、批处理）来配置。
控制内存是否允许超额分配（决定是否容易走到 OOM）
这是最前置、影响最大的参数。它决定了内核在进程申请内存时是否“先答应后兑现”：
- vm.overcommit_memory = 0（默认）：内核按启发式算法判断是否允许分配，相对宽松，OOM 概率中等；适合通用服务器
- vm.overcommit_memory = 1：无条件允许所有 malloc 请求（哪怕远超物理内存+swap），OOM 概率最高；仅适合明确需要大虚拟地址空间且能自控内存使用的场景（如某些科学计算）
- vm.overcommit_memory = 2：严格模式，禁止超额分配。允许分配上限 = swap + 物理内存 × vm.overcommit_ratio（默认 50%，可调高至 80–90）；OOM 概率最低，推荐用于数据库、关键中间件等对稳定性要求高的服务
设定 OOM 发生时的系统级响应方式
避免系统陷入不可控状态，需明确“内存彻底耗尽时该怎么办”：
- vm.panic_on_oom = 0（默认）：触发 OOM Killer，尝试杀进程恢复；生产环境应保持此值
- vm.panic_on_oom = 1：OOM 时直接触发 kernel panic，系统宕机；仅用于调试或必须避免进程被误杀的极特殊场景（如实时控制系统）
- vm.oom_kill_allocating_task = 0（默认）：由内核遍历所有用户进程，按 badness 分数选最该杀的；更公平，推荐保持
- vm.oom_kill_allocating_task = 1：直接杀掉当前申请内存失败的那个进程；可能误伤关键请求线程，不建议启用
影响具体杀哪个进程（精细化保护关键服务）
单靠全局参数不够，还需为关键进程设置内存“豁免权”：
- 每个进程可通过
/proc/[pid]/oom_score_adj设置权重，范围 -1000 到 +1000 - 数据库主进程（如 mysqld、postgres）：启动后立即写入 -500 或 -900，降低被选中的概率
- 容器运行时（如 containerd、dockerd）：建议设为 -500，防止容器引擎被杀导致整机失控
- 监控采集 agent（如 telegraf、node_exporter）：可设为 -100，保障可观测性不中断
- 临时脚本或编译任务：可设为 +500，优先牺牲它们
配套调整：减少误触发与缓解压力
有些参数虽不直接控制 OOM Killer，但显著影响其触发频率和系统表现：
- vm.swappiness = 0 或 1：禁用或大幅降低 swap 使用倾向，避免因换页拖垮 IO 导致假性内存耗尽
- vm.min_free_kbytes：确保内核始终保留一定量不可回收内存，避免因水位过低频繁进入直接回收路径；建议设为物理内存的 1%～3%，最小不低于 64MB
- vm.vfs_cache_pressure = 50～100：降低 inode/dentry 缓存回收倾向，避免文件操作激增时大量释放缓存引发连锁回收压力
