应设为-500而非-1000，因Nginx主进程由systemd管理且worker进程继承其oom_score_adj值；需配合worker数量限制、内存监控及earlyoom等措施，避免系统僵死。
要让 Nginx 主进程在内存紧张时不被内核 OOM Killer 优先选中终止，关键是通过 systemd 合理设置其 oom_score_adj 值——不是设为绝对安全的 -1000，而是调低倾向值（如 -500），同时配合资源约束与监控，避免系统僵死。
为什么只调主进程的 OOM Score 就够了
Nginx 主进程由 systemd 直接管理，worker 进程是其子进程。内核 OOM Killer 在评分时主要依据主进程的 /proc/[pid]/oom_score_adj 值，并沿进程树向下继承影响。只要主进程的评分足够低，整组 worker 的“被杀权重”就会同步下降。无需单独配置每个 worker 的评分，也不建议对 worker 进程做降权操作（它们通常以非 root 用户运行，权限受限）。
正确配置 OOMScoreAdjust（推荐 drop-in 方式）
避免直接修改发行版自带的 /usr/lib/systemd/system/nginx.service，使用 systemd 的 drop-in 机制更安全：
- 执行
sudo systemctl edit nginx - 填入以下内容：
[Service] OOMScoreAdjust=-500
- 保存后运行
systemctl daemon-reload && systemctl restart nginx - 验证：执行
cat /proc/$(pgrep -f "nginx: master")/oom_score_adj，应输出-500
必须同步做的三件事
单设 OOMScoreAdjust 不足以保障稳定，需配套控制资源边界和观测能力：
-
限制 worker 数量与单进程内存：在
nginx.conf中设置worker_processes auto;（不超 CPU 核数），并用worker_rlimit_as 2G;防止单个 worker 虚拟内存失控 -
禁用过严的地址空间限制：检查
systemctl show nginx | grep LimitAS，若值过小（如 64MB），在 drop-in 中加LimitAS=infinity -
开启内存压力监控：部署
earlyoom或启用systemd-oomd，在内核 OOM 触发前主动干预；同时用systemctl status nginx和journalctl -u nginx -n 50关注是否出现 “Killed process” 日志
不推荐设为 -1000 的原因
虽然 -1000 表示“永不被杀”，但会带来严重风险：
- 当系统真实内存耗尽时，Nginx 可能持续申请失败却无法退出，导致请求堆积、连接挂起、监控失联
- 其他关键进程（如数据库、SSH、日志 agent）可能因资源被挤占而异常，运维通道中断
- systemd-oomd 在 cgroup v2 环境下仍可能尝试终止该进程，若配置冲突反而引发行为不可预测
