Linux 内存管理与 OOM Killer 调优：从默认配置到精细化控制
Linux 内存管理与 OOM Killer 调优：从默认配置到精细化控制
一、OOM Killer 的"误杀"：为什么总是杀掉最重要的进程
Linux 的 OOM Killer 是内存耗尽时的最后防线：当系统可用内存低于阈值时，内核选择一个进程终止以释放内存。但 OOM Killer 的选择策略并不总是合理的——它倾向于选择占用内存最多的进程，而这往往是数据库或主应用进程，而非导致内存泄漏的罪魁祸首。
更危险的是 OOM 的突发性：系统可能在几秒内从"内存充足"变为"OOM Kill"，中间没有明显的告警窗口。一个内存泄漏的进程每秒增长 10MB，1GB 的空闲内存只需 100 秒就会耗尽。如果监控告警间隔是 5 分钟，OOM Kill 发生时告警可能还没触发。
二、Linux 内存管理的核心机制
理解 OOM Killer 的行为，需要先理解 Linux 内存管理的几个核心概念。
flowchart TD A[进程申请内存] --> B{物理内存足够？} B -->|足够| C[分配物理页] B -->|不足| D{Swap 可用？} D -->|可用| E[换出页面到 Swap] D -->|不可用| F{触发 OOM Killer} E --> G[释放物理页] G --> C F --> H[计算 OOM Score] H --> I[选择最高分进程] I --> J[发送 SIGKILL] subgraph OOM Score 计算 K[oom_score_adj：手动调整 -1000~1000] L[内存占用比例] M[子进程数量] K --> H L --> H M --> H end关键机制：Linux 使用过度提交（Overcommit）策略，允许进程申请超过物理内存的虚拟内存。当实际使用量接近物理内存上限时，内核通过 OOM Killer 选择进程终止。oom_score_adj 是手动调整 OOM 优先级的接口：-1000 表示"永不杀死"，1000 表示"优先杀死"。
三、生产级调优
3.1 关键进程保护
# 保护数据库进程：降低 OOM Score（优先级降低，更不容易被杀） # -1000 表示永不 OOM Kill echo -1000 > /proc/$(pidof postgres)/oom_score_adj echo -1000 > /proc/$(pidof redis-server)/oom_score_adj # 保护 SSH 守护进程：确保远程访问不中断 echo -1000 > /proc/$(pidof sshd)/oom_score_adj # 优先杀死低优先级任务：提高 OOM Score echo 500 > /proc/$(pidof log-collector)/oom_score_adj # 查看当前进程的 OOM Score cat /proc/$(pidof postgres)/oom_score3.2 内核参数调优
# /etc/sysctl.d/99-memory.conf # Overcommit 策略 # 0 = 启发式（默认，允许适度过度提交） # 1 = 总是允许（不推荐） # 2 = 严格模式（不允许超过 commit_ratio × RAM + Swap） vm.overcommit_memory = 0 # Overcommit 比例（仅 overcommit_memory=2 时生效） # 50 表示允许过度提交到物理内存的 50% vm.overcommit_ratio = 50 # Swap 使用策略 # 0 = 尽量不用 Swap（推荐数据库服务器） # 1 = 内核版本 3.5+ 的默认值 # 60 = 桌面系统默认值 # 100 = 积极使用 Swap vm.swappiness = 1 # 内存压力下的回收策略 # 控制内核回收 inode 和 dentry 缓存的倾向 vm.vfs_cache_pressure = 200 # 最小空闲内存（KB）：低于此值触发主动回收 vm.min_free_kbytes = 524288 # 512MB # OOM Killer 行为控制 # 0 = 不禁用 OOM Killer（默认） # 1 = 禁用 OOM Killer（极度危险，可能导致系统死锁） # 建议保持默认，通过 oom_score_adj 精细控制 kernel.panic_on_oops = 03.3 容器环境中的 OOM 保护
# K8s Pod 配置：QoS 类与 OOM 保护 apiVersion: v1 kind: Pod metadata: name: database-pod spec: containers: - name: postgres image: postgres:16 resources: # Guaranteed QoS：limits = requests # Guaranteed Pod 的 OOM Score 低于 Burstable Pod requests: memory: "4Gi" cpu: "2" limits: memory: "4Gi" cpu: "2" # 容器级 OOM Score 调整 securityContext: procMount: Default # 允许访问 /proc 调整 oom_score_adj --- # 低优先级批处理任务：容易被 OOM Kill apiVersion: v1 kind: Pod metadata: name: batch-job spec: containers: - name: worker image: batch-worker:latest resources: # Burstable QoS：limits > requests requests: memory: "512Mi" cpu: "500m" limits: memory: "2Gi" cpu: "2" # 优先级低于主应用 priorityClassName: low-priority3.4 内存监控与预警
# 早期预警脚本：在 OOM 发生前告警 #!/bin/bash # memory-watchdog.sh THRESHOLD_PERCENT=85 # 内存使用率阈值 ALERT_WEBHOOK="https://hooks.example.com/alert" while true; do # 获取内存使用率 MEM_TOTAL=$(free -m | awk '/^Mem:/{print $2}') MEM_USED=$(free -m | awk '/^Mem:/{print $3}') MEM_PERCENT=$((MEM_USED * 100 / MEM_TOTAL)) if [ $MEM_PERCENT -gt $THRESHOLD_PERCENT ]; then # 获取占用内存最多的进程 TOP_PROCS=$(ps aux --sort=-%mem | head -6) # 发送告警 curl -s -X POST "$ALERT_WEBHOOK" \ -H "Content-Type: application/json" \ -d "{ \"text\": \"内存使用率 ${MEM_PERCENT}% 超过阈值 ${THRESHOLD_PERCENT}%\n\n${TOP_PROCS}\" }" fi sleep 30 done四、OOM 调优的 Trade-offs
Overcommit 严格模式的副作用：设置 overcommit_memory=2 后，进程可能因"虚拟内存超限"而被拒绝分配，即使物理内存还有空闲。对于使用大量虚拟内存的应用（如 Java JVM 的堆预分配），严格模式可能导致启动失败。建议对数据库服务器使用严格模式，对应用服务器使用启发式模式。
Swap 的两面性：禁用 Swap（swappiness=0）可以避免因 Swap I/O 导致的性能抖动，但也意味着内存耗尽时直接触发 OOM Kill，没有缓冲空间。建议对延迟敏感的服务禁用 Swap，对批处理任务保留 Swap。
oom_score_adj 的维护成本：手动调整 oom_score_adj 需要在每次进程重启后重新设置。建议通过 systemd 服务配置或 K8s init container 自动设置。
min_free_kbytes 的设置风险：设置过大会浪费内存（512MB 的空闲内存对 4GB 的机器来说占比过高），设置过小则无法提供足够的缓冲。建议按总内存的 3%-5% 设置，并在生产环境中验证。
五、总结
Linux OOM Killer 调优的核心是"保护关键进程、优先牺牲低优先级任务"。落地路线上，建议先为关键服务设置 oom_score_adj 保护，再调整 overcommit 和 swappiness 参数，最后部署内存监控预警。关键原则：OOM 调优是防御性措施，根本解决方案是修复内存泄漏，min_free_kbytes 提供缓冲窗口，oom_score_adj 实现精细化控制。