Nginx 在内存紧张时可能被 OOM Killer 终止，可通过 systemd 设置 OOMScoreAdjust=-500 降低其被杀倾向；需配合限制 worker 数量、控制单进程内存占用及监控内存压力，避免设为 -1000 以防系统僵死。

当 Nginx 在内存紧张的系统中运行时，Linux 内核的 OOM Killer 可能会将其进程选中并终止。这不是因为 Nginx 本身有 bug，而是内核根据 /proc/[pid]/oom_score_adj 值综合评估后做出的“裁决”。通过 systemd 配置 OOM 评分，可以显著降低 Nginx 被误杀的概率——关键不是设为绝对安全值，而是合理调低其被优先杀死的倾向。

理解 oom_score_adj 的取值逻辑

该值范围是 -1000 到 +1000：
- -1000 表示完全豁免（OOM Killer 永远不选它）
- 0 是默认值（多数普通进程的基准）
- 正值表示更易被杀，负值表示更难被杀
Nginx 主进程通常以 root 启动，但 worker 进程常降权运行（如 www-data），而 systemd 管理的是主进程，因此只需调整主服务单元的 oom_score_adj 即可影响整体存活能力。

在 nginx.service 中配置 oom_score_adj

直接修改 systemd 服务文件，推荐使用 drop-in 方式，避免覆盖原始包管理器提供的 unit 文件：

• 执行 sudo systemctl edit nginx，打开编辑器
• 填入以下内容：

[Service]
OOMScoreAdjust=-500

• 保存退出后，重载配置：sudo systemctl daemon-reload
• 重启服务生效：sudo systemctl restart nginx
• 验证是否生效：cat /proc/$(pgrep -f "nginx: master")/oom_score_adj，应输出 -500

配合其他内存保护措施效果更佳

单靠 OOM 评分不能解决根本问题，需结合实际资源约束：

• 限制 worker 进程数：在 nginx.conf 中设置 worker_processes auto; 或明确数值（如 worker_processes 2;），避免无节制创建进程
• 控制单个 worker 内存占用：合理设置 worker_rlimit_nofile、client_max_body_size 和缓存相关指令（如 proxy_buffering、fastcgi_buffers）
• 监控真实内存压力：用 free -h、systemctl show nginx --property=MemoryCurrent（需启用 MemoryAccounting）或 journalctl -u nginx | grep -i "killed process" 辅助判断是否真被 OOM 杀过

不建议设为 -1000 的原因

虽然 -1000 能彻底豁免，但存在隐患：

• 若 Nginx 因配置错误或攻击导致内存持续暴涨，系统可能因无法回收关键内存而整体僵死
• 部分容器环境或严格审计场景禁止使用 -1000（违反最小权限原则）
• -500 已大幅降低被杀概率，同时保留内核在极端情况下的干预能力，更平衡可靠