Linux服务器内存故障排查实战：从OOM到硬件ECC错误的诊断路径

OOM Killer触发机制与进程定位方法

Linux服务器内存耗尽时，内核的OOM Killer会根据进程的oom_score选择牺牲进程。排查的第一步是确认哪个进程被杀以及为什么被杀：

# 查看OOM Killer日志
grep -i "oom" /var/log/messages
dmesg -T | grep -i "oom"
journalctl -k | grep -i "out of memory"

# 查看当前所有进程的oom_score
cat /proc/*/oom_score | paste - /proc/*/comm - -d' ' | sort -rn | head -20

# 保护关键进程不被OOM杀
echo -1000 > /proc/PID/oom_score_adj

OOM Killer的打分逻辑基于进程占用内存比例+CPU时间权重+nice值调整。内存占用越大的进程得分越高，但不等于占用最多的进程一定被杀——子进程的分数会累加到父进程。排查时需要结合oom_score_adj查看人工调整值，防止运维脚本误设导致关键服务被优先杀掉。

内存泄漏诊断：slab缓存与进程RSS分析

服务器内存持续增长但无明确大进程占用时，问题通常出在内核slab缓存或进程的匿名内存映射：

# 查看slab缓存占用
slabtop -o -s c | head -20

# 查看进程RSS详细拆分
cat /proc/PID/smaps_rollup

# 查看进程内存映射（找出大块匿名映射）
cat /proc/PID/maps | awk '{print $6}' | sort | uniq -c | sort -rn

# 使用smem工具对比RSS和PSS
smem -t -k -s rss | tail -20

slab缓存增长通常与dentry/inode缓存有关。高频率文件操作（如日志轮转、临时文件创建删除）会导致dentry缓存膨胀。清理方法：

# 查看dentry缓存大小
cat /proc/sys/fs/dentry-state

# 安全清理slab缓存（不会影响运行中进程）
echo 2 > /proc/sys/vm/drop_caches
sync; echo 3 > /proc/sys/vm/drop_caches

进程级别的内存泄漏需使用Valgrind或AddressSanitizer定位。对于Go/Java等带GC的语言，先检查GC配置是否合理：

# Go程序查看GC统计
GODEBUG=gctrace=1 ./your_program 2>&1 | grep gc

# Java程序堆内存分析
jmap -heap PID
jmap -histo:live PID | head -30

Swap空间配置与内存压力监控

当物理内存不足时Linux会将内存页换出到Swap，但这会导致严重的IO等待。Swap配置的核心原则：存在但尽量不用。

# 查看Swap使用情况
swapon --show
free -h

# 调整swappiness（值越低越倾向不用Swap）
sysctl vm.swappiness=10

# 永久生效
echo "vm.swappiness=10" >> /etc/sysctl.conf

# 创建Swap文件（紧急场景）
dd if=/dev/zero of=/swapfile bs=1G count=16
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

swappiness=10意味着内核仅在内存剩余约10%时才积极使用Swap。对于数据库服务器（MySQL、Redis），建议设置为1甚至0，因为Swap导致的随机IO会严重拖慢查询延迟。Web服务器可设置为10-30，允许少量Swap换取更充裕的内存缓冲。

硬件ECC错误检测与内存故障预测

服务器使用ECC内存时，可纠正的单比特错误（CE）和不可纠正的多比特错误（UE）会通过EDAC子系统上报。持续出现的CE是内存条即将失效的前兆：

# 查看ECC错误计数
cat /sys/devices/system/edac/mc/mc0/ce_count
cat /sys/devices/system/edac/mc/mc0/ue_count

# 查看具体DIMM的错误率
for i in /sys/devices/system/edac/mc/mc0/csrow*; do
    echo "$(basename $i): CE=$(cat $i/ce_count) UE=$(cat $i/ue_count)"
    echo "  DIMMs: $(cat $i/dimm0_label) $(cat $i/dimm1_label)"
done

# 查看内核EDAC日志
dmesg | grep -i edac
dmesg | grep -i "hardware error"

IPMI/BMC层面也可以监控内存ECC事件：

# 使用ipmitool查看SEL日志中的内存错误
ipmitool sel list | grep -i memory
ipmitool sel list | grep -i ecc

# 查看当前传感器状态
ipmitool sensor list | grep -i memory

当CE计数持续增长（日增量>100次）时，建议提前更换对应DIMM，避免UE导致的内核panic。云服务器用户需要通过云平台监控面板查看底层硬件状态，无法直接访问EDAC。

内存压力测试与容量规划

新服务器上线前进行内存压力测试，可在负载高峰前暴露潜在故障：

# 使用stress-ng进行内存压力测试
stress-ng --vm 8 --vm-bytes 80% --timeout 24h --metrics-brief

# 使用memtester测试单根DIMM（需离线执行）
memtester 4G 3  # 测试4GB区域，3轮

# 使用mbw测试内存带宽
mbw -n 5 1024

容量规划方面，服务器内存使用率建议控制在70%以下，留出30%作为缓冲。对于运行Java/Go应用的服务器，GC的内存波动可达20%，需在规划时预留。使用Prometheus的node_memory规则做告警：

# Prometheus告警规则
- alert: MemoryUsageHigh
  expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.85
  for: 5m
  labels:
    severity: warning
  annotations:
    summary: "内存使用率超过85%"
    description: "{{ $labels.instance }} 可用内存不足15%"

内存故障排查的核心思路：先确认OOM是进程泄漏还是总量不足，再区分软件问题和硬件ECC错误，最后结合压力测试验证。物理机的ECC监控和云服务器的内存水位告警缺一不可。