Linux服务器内存泄漏排查与OOM Killer调优实战

Linux内存管理机制与OOM Killer触发原理

Linux服务器内存泄漏是线上事故中最常见的故障类型之一。进程持续分配内存但不释放，导致可用内存逐步耗尽，最终触发OOM Killer强制杀掉进程。理解内存管理机制和OOM Killer的决策逻辑，是快速定位和解决此类问题的前提。这篇实战指南覆盖内存泄漏定位、OOM Killer调优、cgroup内存限制三个核心场景，附带可直接执行的排查命令和调优配置。

内存泄漏排查工具链：从sar到eBPF

第一步：确认内存消耗趋势

用sar记录历史内存使用数据，判断是否存在持续增长趋势：

# 安装sysstat
apt install sysstat -y

# 每隔10秒采集一次，采集6次
sar -r 10 6

# 输出关键字段说明：
# kbmemavail - 可用内存（含可回收缓存）
# kbmemused  - 已用内存（减去缓存）
# kbbuffers  - buffer缓存
# kbcached   - page cache

如果kbmemused持续增长且kbmemavail持续下降，基本可以确认存在内存泄漏。

第二步：定位问题进程

# 按RSS排序，显示前10个进程
ps aux --sort=-%mem | head -11

# 更精确的方式：读取smaps
# 查看进程PID=12345的内存映射
cat /proc/12345/smaps_rollup

# 输出示例：
# Rss:           2048000 kB
# Pss:           1980000 kB
# Shared_Clean:     1200 kB
# Shared_Dirty:    45000 kB
# Private_Clean:   89000 kB
# Private_Dirty: 1900300 kB

Private_Dirty持续增长通常意味着堆内存泄漏——进程分配了内存，写入了数据，但未释放。

第三步：使用eBPF实时追踪内存分配

# 使用bcc工具集的memleak
# 追踪PID=12345的未释放内存分配
/usr/share/bcc/tools/memleak -p 12345

# 输出示例：
# Allocation size 1024, count 84521, total 82541024 byte
#   alloced at:
#       alloc_page+0x1a
#       kmalloc+0x3e
#       my_module_alloc+0x52
#       ...

memleak会追踪所有malloc但不free的分配调用栈，直接暴露泄漏点。对于Java/Go应用，用语言级工具更高效：

# Java：jmap导出堆直方图
jmap -histo:live 12345 | head -30

# Go：pprof内存分析
curl http://localhost:6060/debug/pprof/heap > heap.prof
go tool pprof -top heap.prof

OOM Killer决策逻辑与日志分析

当系统可用内存低于min_watermark，内核触发直接内存回收（direct reclaim）；如果回收后仍不足，触发OOM Killer。选择杀哪个进程的逻辑基于oom_score：

# 查看进程的oom_score
cat /proc/12345/oom_score

# oom_score计算公式（简化版）：
# score = (进程RSS / 总内存) * 1000 + oom_score_adj
# 分数越高，越优先被杀

OOM Killer日志分析

# 查看内核日志中的OOM记录
dmesg | grep -i "out of memory" -A 20

# 或用journalctl
journalctl -k --since "1 hour ago" | grep -i "oom" -A 10

# 典型日志格式：
# Out of memory: Killed process 12345 (java) total-vm:8388608kB, anon-rss:7864320kB
# oom_score_adj 值: 0

关键信息：被杀进程的PID、进程名、anon-rss（匿名内存占用）、oom_score_adj值。

OOM Killer调优：保护关键进程

方案一：调整oom_score_adj

# 保护关键进程不被OOM杀掉（-1000表示永远不会被选为牺牲进程）
echo -1000 > /proc/12345/oom_score_adj

# 让非核心进程优先被杀
echo 500 > /proc/67890/oom_score_adj

# 永久生效：修改systemd service
# /etc/systemd/system/myapp.service
[Service]
OOMScoreAdjust=-1000

方案二：调整vm.overcommit_memory

# 0 - 启发式overcommit（默认）
# 1 - 始终允许overcommit
# 2 - 严格禁止overcommit，按vm.overcommit_ratio计算允许分配总量

# 生产环境推荐值2，配合合理的overcommit_ratio
sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=80  # 允许分配 swap + 80% * RAM

设置为2后，malloc在总量超限时直接返回NULL，而不是触发OOM Killer。应用程序需要处理malloc失败，但系统不会杀进程。

方案三：earlyoom替代内核OOM

# 安装earlyoom，在内存紧张但未触发内核OOM前主动干预
apt install earlyoom -y

# 配置：可用内存低于10%或可用swap低于10%时开始杀进程
# /etc/default/earlyoom
EARLYOOM_ARGS="-r 3600 -m 10 -s 10 --prefer '(cron|rsyslog)'"

systemctl enable earlyoom
systemctl start earlyoom

earlyoom的优势：比内核OOM Killer更早介入，避免系统进入完全无响应状态。

cgroup v2内存限制与OOM事件监听

容器化场景下，用cgroup内存限制替代全局OOM管理更精细：

# 创建cgroup并设置内存限制
mkdir /sys/fs/cgroup/myapp
echo 4G > /sys/fs/cgroup/myapp/memory.max
echo 512M > /sys/fs/cgroup/myapp/memory.swap.max

# 将进程加入cgroup
echo 12345 > /sys/fs/cgroup/myapp/cgroup.procs

# 监听cgroup OOM事件
# memory.events中oom_kill计数增加表示触发了cgroup级别OOM
cat /sys/fs/cgroup/myapp/memory.events

# 输出示例：
# low 0
# high 0
# max 12        ← 内存触及limit的次数
# oom 3          ← cgroup内OOM事件次数
# oom_kill 3     ← cgroup内被杀进程数

结合inotifywait做实时OOM告警：

inotifywait -m -e modify /sys/fs/cgroup/myapp/memory.events |
while read path action file; do
    oom_kills=$(grep oom_kill /sys/fs/cgroup/myapp/memory.events | awk '{print $2}')
    echo "[ALERT] cgroup myapp oom_kill count: $oom_kills at $(date)"
done

内存泄漏常见根因与修复方案

根因1：未关闭的资源

数据库连接、文件句柄、HTTP连接未关闭导致内存持续增长。修复方案：确保所有资源在finally块或context manager中关闭。

# Python：用context manager确保连接释放
import psycopg2

def query_data(sql):
    with psycopg2.connect(DSN) as conn:
        with conn.cursor() as cur:
            cur.execute(sql)
            return cur.fetchall()
    # 离开with块自动关闭连接

根因2：缓存无上限

本地缓存没有容量限制，数据只增不减。修复：用LRU缓存替代HashMap。

# Python：用functools.lru_cache限制缓存大小
from functools import lru_cache

@lru_cache(maxsize=10000)
def get_user_info(user_id):
    return db.query("SELECT * FROM users WHERE id = %s", user_id)

# 监控缓存命中率
print(get_user_info.cache_info())
# CacheInfo(hits=8500, misses=1500, maxsize=10000, currsize=10000)

根因3：事件监听器未注销

注册了事件回调但未注销，导致对象无法被GC回收。在Spring中常见于动态创建的EventListener：

// 修复：使用WeakHashMap或手动注销监听器
@PreDestroy
public void cleanup() {
    eventPublisher.removeListener(this.dynamicListener);
}

内存监控告警配置模板

# Prometheus告警规则：内存相关
groups:
  - name: memory_alerts
    rules:
      - alert: MemoryUsageHigh
        expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.85
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "内存使用率超过85%"

      - alert: OOMKillDetected
        expr: increase(node_oom_kills_total[5m]) > 0
        labels:
          severity: critical
        annotations:
          summary: "检测到OOM Kill事件"

内存泄漏排查不是一次性工作。线上环境建议配置基于cgroup的内存水位监控，在内存占用80%时告警，在90%时自动dump堆快照，为后续分析保留现场。