Linux内存管理调优实战：OOM Killer机制分析与swap分区配置

Linux服务器在运行高负载应用时，内存耗尽导致的OOM Kill是运维中高频遇到的问题。进程被内核强制终止，日志中出现”Out of memory: Killed process”记录，但根因分析往往不够清晰。Linux内存管理涉及物理内存分配、swap交换、OOM Killer触发机制等多个层面，理解这些机制对服务器故障排查和性能调优至关重要。

Linux内存管理基础与关键指标

Linux内核将物理内存划分为多个zone，每个zone维护独立的free_area链表管理空闲页面。应用通过brk/mmap系统调用申请内存，内核采用伙伴系统（Buddy System）分配物理页框。

关键内存指标通过/proc/meminfo查看：

# 查看内存概况
cat /proc/meminfo

# 输出关键字段：
# MemTotal       - 物理内存总量
# MemFree        - 完全空闲内存
# MemAvailable   - 可用内存（含可回收缓存）
# Buffers        - 块设备缓存
# Cached         - 页面缓存
# SwapCached     - 同时在内存和swap中的页面
# SwapTotal      - swap总量
# SwapFree       - swap空闲量

# 实时监控内存使用
# 按进程排序内存占用
ps aux --sort=-%mem | head -20

# 使用smem查看进程实际物理内存（PSS）
smem -rs pss | head -20

# 使用free查看（关注available而非free）
free -h
#               total   used   free   shared  buff/cache  available
# Mem:           62Gi   28Gi   3.2Gi   0.5Gi      31Gi        30Gi
# Swap:          8Gi    2Gi    6Gi

MemAvailable是评估内存压力的核心指标，它等于MemFree加上可快速回收的缓存（不含被进程通过mlock锁定的页面）。当MemAvailable低于MemTotal的10%时，系统进入内存紧张状态。

OOM Killer触发机制详解

当物理内存和swap均耗尽，且无法通过回收缓存释放足够内存时，内核触发OOM Killer。OOM Killer通过oom_score对每个进程打分，选择分数最高的进程终止。

oom_score计算逻辑：

# 查看进程的oom_score
cat /proc/<pid>/oom_score

# 查看oom_score_adj（可手动调整）
cat /proc/<pid>/oom_score_adj

# oom_score计算公式（简化）：
# score = (rss / total_rss) * 1000 + (swap_usage / total_swap) * 1000
# oom_score_adj范围：-1000到1000
# adj=-1000 表示该进程永远不会被OOM Kill
# adj=1000  表示该进程优先被OOM Kill

# 保护关键进程不被OOM Kill
echo -1000 > /proc/<pid>/oom_score_adj

# 或在systemd service中配置
# /etc/systemd/system/myservice.service
[Service]
OOMScoreAdjust=-500
ExecStart=/usr/bin/myapp

# 全局OOM行为配置
# /etc/sysctl.conf
vm.panic_on_oom = 0          # 0=触发OOM Killer，1=内核panic
vm.oom_kill_allocating_task = 0  # 0=按score选择，1=杀掉触发OOM的进程
vm.overcommit_memory = 0     # 0=启发式判断，1=允许超分，2=严格限制
vm.overcommit_ratio = 50     # overcommit_memory=2时，允许分配=swap+(ratio%*ram)

# 生效
sysctl -p

overcommit_memory的三个模式需要根据业务场景选择：

模式0（默认）：内核启发式评估分配请求，大概率拒绝明显不合理的超分。适合大多数服务器场景。

模式1：允许任意超分，不做限制。适合科学计算等确定会使用全部申请内存的场景，但风险是触发OOM概率更高。

模式2：严格模式，总可用虚拟内存=swap+(overcommit_ratio% × 物理内存)。生产数据库服务器建议使用此模式，ratio设为80。

swap分区配置与性能影响

swap是磁盘上的交换分区，当物理内存不足时内核将不活跃页面换出到swap。swap的读写速度远低于物理内存，频繁swap会导致系统性能急剧下降。

# 创建swap文件（推荐方式，比分区更灵活）
# 创建8GB swap文件
dd if=/dev/zero of=/swapfile bs=1M count=8192
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile

# 永久生效（写入fstab）
echo '/swapfile none swap sw 0 0' >> /etc/fstab

# 查看swap状态
swapon --show
# NAME      TYPE  SIZE  USED  PRIO
# /swapfile file  8G    2G    -2

# 查看swap使用详情
cat /proc/swaps

# swappiness参数控制内核swap倾向
# 范围0-100，默认60
# 0=尽量不用swap，100=积极使用swap
# 生产数据库服务器建议设为10
# 桌面/通用服务器设为60

# 临时调整
sysctl vm.swappiness=10

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

#vfs_cache_pressure控制目录项和inode缓存回收倾向
#范围0-1000，默认100
#值越大，内核越倾向于回收dentry/inode缓存
echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.conf
sysctl -p

cgroup内存限制与容器场景OOM

容器环境中的OOM更常见，因为cgroup对每个容器施加内存限制。容器内进程总内存超过limit时触发cgroup OOM，与系统级OOM独立。

# 查看容器cgroup内存限制
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.limit_in_bytes
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.usage_in_bytes
cat /sys/fs/cgroup/memory/docker/<container_id>/memory.failcnt

# Docker运行时指定内存限制
docker run -d \
    --name myapp \
    --memory=4g \
    --memory-swap=6g \
    --memory-swappiness=10 \
    --oom-kill-disable=false \
    myimage:latest

# Kubernetes中通过resources限制
# deployment.yaml
spec:
  containers:
  - name: app
    resources:
      requests:
        memory: "2Gi"
      limits:
        memory: "4Gi"

# cgroup v2内存监控
# 查看容器内存使用
cat /sys/fs/cgroup/system.slice/docker-*.scope/memory.current
cat /sys/fs/cgroup/system.slice/docker-*.scope/memory.max
cat /sys/fs/cgroup/system.slice/docker-*.scope/memory.events

# memory.events输出：
# oom 3              - 触发OOM次数
# oom_kill 3         - OOM Kill次数
# oom_group_kill 0   - cgroup级别OOM Kill

内存泄漏排查工具与方法

当进程内存持续增长不释放，需要排查是否存在内存泄漏。

# 使用valgrind检测C/C++程序内存泄漏
valgrind --leak-check=full --show-leak-kinds=all \
    --track-origins=yes --verbose \
    --log-file=valgrind-out.txt ./myprogram

# 使用pmap查看进程内存映射
pmap -x <pid> | tail -5
# 输出 RSS（实际物理内存）和虚拟内存映射

# 使用/proc直接查看
cat /proc/<pid>/status | grep -i vm
# VmPeak  - 峰值虚拟内存
# VmSize  - 当前虚拟内存
# VmRSS   - 实际物理内存
# VmSwap  - swap使用量

# Java程序内存分析
# 导出堆dump
jmap -dump:format=b,file=heap.hprof <pid>
# 使用MAT或jhat分析
jhat -J-Xmx2g heap.hprof

# 使用systemd-cgtop实时监控cgroup内存
systemd-cgtop

# 使用bcc/eBPF追踪内存分配
# 追踪brk系统调用
/usr/share/bcc/tools/brkstack.py

# 追踪大页分配
/usr/share/bcc/tools/memleak.py -p <pid>

生产环境内存调优清单

服务器安全加固与内存调优的关键配置项：

swap大小：物理内存32GB以下建议swap=物理内存×1-2，32GB以上建议swap=8-16GB固定值。数据库服务器可适当增大swap但不依赖swap运行。

swappiness：数据库/中间件服务器设为10，通用Web服务器保持默认60，虚拟化宿主机设为5。过低会导致内存紧张时直接OOM而非swap，过高会导致性能下降。

transparent_hugepage：THP将4KB页面合并为2MB大页，减少TLB miss。但某些数据库（如Oracle、MongoDB）与THP存在兼容性问题，建议禁用。

# 禁用THP
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# 永久禁用（systemd服务）
cat > /etc/systemd/system/disable-thp.service << 'EOF'
[Unit]
Description=Disable Transparent Huge Pages
[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag"
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
EOF
systemctl enable disable-thp
systemctl start disable-thp

关键进程保护：通过oom_score_adj=-1000保护systemd、sshd、数据库主进程等关键服务。注意不要保护所有进程，否则OOM时无进程可杀会导致内核panic。

监控告警：配置MemAvailable低于阈值告警（建议15%），swap使用率告警（建议50%），OOM Kill事件即时告警。使用node_exporter采集指标，Prometheus Alertmanager推送通知。