关键业务进程应设oom_score_adj为-1000以确保oom时永不被杀；systemd服务可通过oomscoreadjust=-1000长期配置；辅以cgroup内存限制、earlyoom前置干预及合理内核参数调优，实现双层防护。

关键业务进程（如数据库、API网关、消息队列）在内存紧张时必须优先存活，核心不是阻止OOM发生，而是确保它们在OOM Killer触发时永不被选中终止。

设置 oom_score_adj 为 -1000

这是最直接有效的保护手段。值为-1000表示该进程在OOM事件中被内核完全跳过，不参与评分和杀戮。

• 对已运行的进程：获取PID后立即生效
  echo -1000 | sudo tee /proc//oom_score_adj
• 对 systemd 服务（推荐长期配置）：
  执行 sudo systemctl edit ，添加：
  [Service]
  OOMScoreAdjust=-1000
  然后重载并重启：
  sudo systemctl daemon-reload && sudo systemctl restart
• 常见服务建议值：
  • sshd / journald：-1000（保障运维通道与日志基础能力）
  • MySQL / PostgreSQL：-500 至 -800（保留一定弹性，避免极端场景下系统失控）
  • Nginx / Envoy：-300（高可用网关需强保护，但不宜全设-1000）

限制非关键进程内存使用

防止某个临时任务或监控脚本突发占满内存，拖垮整个节点。

• 用 cgroup v2 限制低优先级进程组：
  sudo mkdir -p /sys/fs/cgroup/low-priority
  echo "max 512M" | sudo tee /sys/fs/cgroup/low-priority/memory.max
  echo | sudo tee /sys/fs/cgroup/low-priority/cgroup.procs
• 对 cron 任务或后台脚本，启动前加：
  ulimit -v 2097152（限制虚拟内存 2GB）
• Java 应用务必设置 -Xmx，且不超过物理内存的 70%，并启用 -XX:+UseContainerSupport（K8s 环境）

调优内核 OOM 行为策略

让 OOM Killer 更可控、更公平，而非依赖默认随机性。

• 确认 vm.panic_on_oom=0（默认值），避免整机 panic
• 设置 vm.oom_kill_allocating_task=0（默认），使内核按综合 badness 分数选进程，而非简单杀死当前申请内存的进程——这对数据库事务类场景更合理
• 谨慎启用 vm.overcommit_memory=2，配合 vm.overcommit_ratio，可显著降低虚假 OOM 概率

部署 earlyoom 或 OOMD 作为前置防线

Linux 原生 OOM Killer 是“最后一搏”，而 earlyoom 或 Facebook 的 OOMD 可在内存真正耗尽前主动干预，给关键进程留出缓冲时间。

• earlyoom：安装后配置为仅在可用内存 ≤8% 时触发，发送 SIGTERM 给低优先级进程
• OOMD：需启用 cgroup v2 和 PSI（压力停滞信息），要求内核 ≥4.20；Swap 配置不可省略（建议至少等于物理内存），用于提供预警窗口
• 验证 OOMD 基础：
  mount | grep cgroup 应显示 cgroup2 类型
  zcat /proc/config.gz | grep CONFIG_PSI 应返回 CONFIG_PSI=y