如何调整Nginx进程的oom_score_adj来避免被系统OOM killer误杀？

在Linux系统中，当物理内存与交换空间耗尽时，内核的OOM killer机制会依据每个进程的oom_score_adj数值来选举牺牲者。Nginx作为常见的Web服务，通常常驻内存并持有连接，容易在内存争抢中被选中终止，造成业务中断。理解并合理调整Nginx相关进程的oom_score_adj，是运维中保障服务韧性的实用手段。

oom_score_adj机制与Nginx进程模型的关系

oom_score_adj是内核提供的一个针对每个进程的调优参数，取值范围从-1000到1000。该数值会被计入oom_score的计算公式，最终分数越高，进程在OOM时被杀的可能性越大。负值表示进程受到保护，其中-1000意味着完全禁止OOM killer终止此进程。在proc文件系统中，对应路径为/proc/<pid>/oom_score_adj，可直接写入整数值进行修改。

Nginx采用多进程模型，包含一个master进程与多个worker进程。master负责读取配置、绑定端口与管理worker；worker处理实际请求，内存占用往往随连接数波动。若仅调低master的oom_score_adj，worker仍可能因高分被杀，导致服务虽在但无法处理流量。因此调整时必须覆盖两类进程，或借助父进程继承特性统一设定。

另一个容易忽视的点是，systemd拉起的服务其oom_score_adj可能受服务单元内配置影响，而Nginx自身也可以通过配置文件中的worker_processes等指令间接改变资源画像。在容器环境里，cgroup内存限制会先于全局OOM触发，此时oom_score_adj作用范围限于cgroup内部，需要调整思路避免混淆。

通过systemd与启动脚本调整Nginx的oom_score_adj

对于使用systemd管理的Nginx服务，最干净的做法是在单元文件中增加配置。可利用ExecStartPre钩子，在Nginx启动前为即将生成的master进程设定保护值。由于systemd默认会继承服务管理器的分数，我们可以在启动前写入当前进程的分数，再由Nginx继承给子进程。下面示例展示了一个简单的service片段：

[Service]
ExecStartPre=/bin/sh -c 'echo -300 > /proc/self/oom_score_adj'
ExecStart=/usr/sbin/nginx -g "daemon off;"
# 若需单独保护worker，可结合nginx配置或post脚本

上述写法将systemd启动Nginx前的自身分数调低，Nginx的master会继承该值。但worker是否继承取决于内核调度，一般子进程会拷贝父进程的分数，所以master为-300时worker通常同样受保护。如果系统中存在多实例Nginx，应分别设定不同单元，避免相互覆盖。

不使用systemd的旧版环境，可以包装启动脚本，在调用nginx二进制前写/proc/self/oom_score_adj，或在nginx启动后用脚本遍历其pid批量修改。下面给出一个bash片段，演示启动后修正所有Nginx进程分数：

#!/bin/bash
/usr/sbin/nginx
for pid in $(pgrep nginx); do
  echo -300 > /proc/$pid/oom_score_adj
done

这种脚本方式直观但存在竞态：Nginx刚启动到脚本改分数之间若有OOM，仍可能中招。因此它适合内存充裕、仅作长期调优的场景，生产高危环境应优先采用systemd继承法或内核级保护。

调整策略的风险评估与配套监控手段

将Nginx的oom_score_adj设得过低，比如-1000，虽然几乎不会被杀，但会迫使OOM killer转向其他进程。若服务器上同时运行内存泄漏的应用，该系统进程可能替代Nginx被杀，引发数据库或缓存崩溃，故障面反而扩大。合理的做法是适度保护，例如-200到-300，既降低误杀率，又保留极端情况下的牺牲可能。

此外，oom_score_adj只是缓解而非根治。真正的内存压力应通过cgroup限制、worker连接数上限、缓存策略优化来解决。建议配合node_exporter等工具采集oom_kill计数与Nginx常驻内存，当worker内存增长异常时自动告警。下面用一段伪代码说明监控逻辑：

# 伪代码：检查Nginx worker内存并动态调整分数
import os
for pid in pgrep("nginx: worker"):
    rss = get_rss(pid)
    if rss > 500 * 1024 * 1024:
        write_oom_score_adj(pid, -100)
    else:
        write_oom_score_adj(pid, -300)

通过动态调节，可以在正常时段给予强保护，在内存膨胀初期适度放开以配合OOM筛选。这种策略比静态写死更适应复杂业务。总之，oom_score_adj是精细旋钮，需放进整体稳定性框架中考量，而非单独依赖。

Nginxoom_score_adjOOM_killer修改时间：2026-08-18 05:56:25