oom_score_adj：Linux 内存管理的秘密武器

目录

• 什么是 OOM Killer？
• oom_score 和 oom_score_adj 的关系
  • oom_score 的自动计算
• 如何查看和调整 oom_score_adj
  • 查看当前值
  • 调整 oom_score_adj
• 实际应用场景
  • 1. 保护关键系统服务
  • 2. 容器环境中的使用
  • 3. 桌面环境优化
• 高级技巧和注意事项
  • 永久性配置
  • 监控 OOM 事件
  • 编写安全脚本
• 最佳实践建议
• 总结

---

当系统内存耗尽时，哪个进程会被优先终结？答案就在 oom_score_adj 这个神秘的参数中。

---

什么是 OOM Killer？

在深入探讨 oom_score_adj 之前，我们需要先了解 Linux 系统的内存管理机制。当系统内存严重不足，无法满足进程需求时，Linux 内核会触发一种保护机制——Out-Of-Memory (OOM) Killer。

OOM Killer 的任务很残酷但必要：选择一个或多个进程终止，以释放内存，确保系统继续运行。但如何选择牺牲品呢？这就是 oom_score 和 oom_score_adj 发挥作用的地方。

---

oom_score 和 oom_score_adj 的关系

每个进程都有两个相关参数：

1. oom_score - 由内核计算的"可终结性"分数，范围从 0 到 1000
2. oom_score_adj - 用户可调整的偏移量，范围从 -1000 到 1000

最终的可终结性分数计算公式为：

最终分数 = oom_score + oom_score_adj

内核会优先终止最终分数最高的进程。

oom_score 的自动计算

内核根据多种因素自动计算每个进程的 oom_score：

• 进程使用的内存量（RSS）
• 进程运行时间（运行时间越长，分数越低）
• 进程的优先级（nice值）
• 进程类型（系统进程 vs 用户进程）
• 子进程的内存使用情况

---

如何查看和调整 oom_score_adj

查看当前值

# 查看进程的 oom_score 和 oom_score_adj
cat /proc/[PID]/oom_score
cat /proc/[PID]/oom_score_adj

# 示例：查看所有进程的 oom 相关信息
ps -eo pid,comm,oom_score,oom_score_adj | sort -k3 -nr | head -10

调整 oom_score_adj

# 将进程保护起来（使其不易被 OOM Killer 终止）
echo -1000 > /proc/[PID]/oom_score_adj

# 将进程标记为优先终止目标
echo 1000 > /proc/[PID]/oom_score_adj

# 使用系统工具调整
sudo chmod -17 [PID]    # 保护进程
sudo chmod +18 [PID]    # 标记为可优先终止

---

实际应用场景

1. 保护关键系统服务

# 保护 SSH 服务（避免在内存不足时失去远程连接）
echo -1000 > /proc/$(pidof sshd)/oom_score_adj

# 保护数据库服务
echo -500 > /proc/$(pidof mysqld)/oom_score_adj

2. 容器环境中的使用

在 Docker 和 Kubernetes 中，oom_score_adj 有特别重要的应用：

# Docker 容器的 OOM 优先级调整
docker run -m 512m --oom-kill-disable=false --oom-score-adj=500 nginx

# 在 Kubernetes 中配置
# pod.yaml 示例片段
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  containers:
  - name: myapp
    image: myapp:latest
    resources:
      requests:
        memory: "256Mi"
      limits:
        memory: "512Mi"

Kubernetes 会自动为 Pod 设置 oom_score_adj 值，基于其 QoS（服务质量）等级：

• Guaranteed: -998
• Burstable: 2-999
• BestEffort: 1000

3. 桌面环境优化

# 保护桌面环境关键组件
protect_desktop_processes() {
    # 保护显示管理器
    for pid in $(pidof gnome-shell); do
        echo -100 > /proc/$pid/oom_score_adj
    done
    
    # 保护文件管理器
    for pid in $(pidof nautilus); do
        echo -50 > /proc/$pid/oom_score_adj
    done
}

---

高级技巧和注意事项

永久性配置

通过 systemd 服务配置：

# /etc/systemd/system/myapp.service.d/oom.conf
[Service]
# 完全保护（等效于 oom_score_adj=-1000）
OOMScoreAdjust=-1000

# 或指定具体值
# OOMScoreAdjust=-500

监控 OOM 事件

# 查看内核日志中的 OOM 事件
sudo dmesg | grep -i "killed process"

# 使用专门工具监控
sudo apt install linux-tools-common
sudo perf record -e oom:oom_kill_process -ag

编写安全脚本

#!/bin/bash
# protect_important_processes.sh

# 安全的 oom_score_adj 设置函数
set_oom_adj() {
    local pid=$1
    local adj=$2
    
    # 验证进程是否存在
    if [ ! -d "/proc/$pid" ]; then
        echo "进程 $pid 不存在"
        return 1
    fi
    
    # 验证参数范围
    if [ $adj -lt -1000 ] || [ $adj -gt 1000 ]; then
        echo "调整值必须在 -1000 到 1000 之间"
        return 1
    fi
    
    # 设置值
    echo $adj > /proc/$pid/oom_score_adj 2>/dev/null
    
    if [ $? -eq 0 ]; then
        echo "已设置进程 $pid 的 oom_score_adj 为 $adj"
    else
        echo "设置失败，可能需要 root 权限"
        return 1
    fi
}

# 保护关键进程
set_oom_adj $(pidof sshd) -1000
set_oom_adj $(pidof dockerd) -500

---

最佳实践建议

1. 谨慎使用极端值：将 oom_score_adj 设为 -1000 意味着进程几乎不可能被 OOM Killer 终止，可能导致系统完全僵死。

2. 分层保护策略：

   • -1000：绝对保护（仅用于绝对不能终止的进程）
   • -500 到 -100：高度保护（关键服务）
   • 0：默认值
   • 100 到 500：可优先终止（缓存进程、批量任务）
   • 1000：优先终止（测试进程、不重要任务）

3. 监控和调整：定期检查系统日志，根据实际情况调整策略。

4. 结合内存限制使用：在现代容器和虚拟化环境中，结合使用 cgroup 内存限制和 oom_score_adj 调整。

---

总结

oom_score_adj 是 Linux 系统中一个强大但常被忽视的工具，它让我们能够在内存危机发生时主动影响系统的决策。通过合理配置，我们可以：

• 确保关键服务的高可用性
• 优化系统稳定性
• 在容器环境中实现精细化的资源管理
• 避免重要工作被意外终止

记住，权力越大责任越大。错误的配置可能导致 OOM Killer 无法有效工作，使系统陷入更深的危机。始终在理解系统整体内存需求的基础上，谨慎地使用这一功能。