最有效手段是精准设置oom_score_adj为-1000以豁免关键进程，辅以cgroup内存限制、Java堆参数调优、内核OOM策略调整及earlyoom前置防护。
关键业务进程（如数据库、API网关、消息队列）在内存紧张时必须优先存活，核心不是阻止OOM发生，而是确保它们在OOM Killer决策中拥有最高生存权重。最有效手段是精准设置 oom_score_adj，辅以资源隔离与系统级调优。
给关键进程设固定 oom_score_adj = -1000
该值表示内核在OOM事件中完全跳过该进程，不参与评分和终止候选。
- 对已运行进程：获取 PID 后立即生效
echo -1000 | sudo tee /proc/<PID>/oom_score_adj - 对 systemd 服务（推荐长期配置）：
执行sudo systemctl edit <service-name>，添加：
[Service] OOMScoreAdjust=-1000
再执行 sudo systemctl daemon-reload && sudo systemctl restart <service-name>
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 常见服务建议值（兼顾保护与系统可控性）：
• sshd、systemd-journald：-1000（保障运维链路）
• MySQL / PostgreSQL：-500 至 -800（保留弹性，防极端失控）
• Nginx / Envoy：-300（强保护但避免全设 -1000）
限制非关键进程的内存使用范围
防止临时任务或监控脚本突发占满内存，拖垮整个节点。
- 用 cgroup v2 限制低优先级任务：
sudo mkdir -p /sys/fs/cgroup/low-priorityecho "max 512M" | sudo tee /sys/fs/cgroup/low-priority/memory.maxecho <PID> | 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（如设为 80），可大幅降低虚假 OOM 概率
部署 earlyoom 作为前置防线
原生 OOM Killer 是“最后一搏”，earlyoom 可在内存真正耗尽前主动干预，为关键进程争取缓冲时间。
- 安装后配置触发阈值，例如仅在可用内存 ≤ 8% 时发送 SIGTERM
- 配合 systemd 管理，支持优雅降级与日志记录
- 与 oom_score_adj 形成双层防护：earlyoom 清理轻量进程，OOM Killer 作为兜底
