Linux OOM Killer内存回收触发机制与cgroups资源限制配置实战

小编 • 9小时前 • 服务器

Linux OOM Killer（Out Of Memory Killer）是内核在系统物理内存耗尽时的应急机制。当可用内存低于阈值且无法通过正常回收释放足够页面时，内核选择性杀掉占用内存最多的进程以保全系统。生产环境中OOM Killer的误杀往往导致关键服务意外中断。通过cgroups对进程组设置内存上限，可以在进程层面精确控制内存使用，避免单个服务拖垮整台服务器。本文分析OOM Killer的触发流程和评分算法，并给出cgroups v2内存限制的完整配置方案。

OOM Killer触发路径与内核内存分配流程

Linux内存分配采用overcommit策略，进程申请的虚拟地址空间可以超过物理内存总量。当进程实际访问分配的内存页触发缺页中断时，内核才真正分配物理页面。如果此时物理内存和swap空间均已耗尽，内核进入__alloc_pages_slowpath路径：先唤醒kswapd内核线程进行后台内存回收，再执行直接内存回收（direct reclaim）同步释放干净页，若仍无法满足分配需求则触发OOM Killer。

cat /proc/sys/vm/overcommit_memory
# 0: 启发式判断，默认值
# 1: 总是允许overcommit
# 2: 严格模式，commit总量不超过swap+ratio*RAM

OOM Score评分算法与进程选择策略

内核使用oom_badness()函数为每个进程计算OOM评分，选择得分最高的进程杀掉。评分核心因素：进程驻留物理内存页数（rss_points）、swap页数（swap_points）、页表占用内存（pgtable_points），子进程和线程叠加到父进程。通过/proc/[pid]/oom_score查看分值，/proc/[pid]/oom_score_adj调整评分权重：

# 保护关键进程，降低被杀概率（范围-1000到1000）
echo -500 > /proc/$(pidof nginx)/oom_score_adj

# 确保某进程优先被杀
echo 500 > /proc/$(pidof some_worker)/oom_score_adj

oom_score_adj=-1000时该进程永不被OOM Killer选中，但可能导致其他进程被杀。生产环境对MySQL、Redis等核心服务设置-500到-900的值。

cgroups v2内存限制配置与层次结构

cgroups v2采用单一层级结构，所有控制器挂载在同一目录下。配置步骤：

# 创建应用控制组
mkdir -p /sys/fs/cgroup/app/myapp

# 设置内存上限为2GB
echo 2147483648 > /sys/fs/cgroup/app/myapp/memory.max

# 设置swap上限为1GB
echo 1073741824 > /sys/fs/cgroup/app/myapp/memory.swap.max

# 启用内存控制器
echo "+memory" > /sys/fs/cgroup/app/cgroup.subtree_control

# 将进程加入控制组
echo $(pidof myapp) > /sys/fs/cgroup/app/myapp/cgroup.procs

systemd集成cgroups内存限制配置

生产环境通过systemd管理服务，可直接在unit文件中配置资源限制：

# /etc/systemd/system/myapp.service
[Service]
ExecStart=/usr/bin/myapp
MemoryMax=2G
MemoryHigh=1800M
MemorySwapMax=1G
MemoryAccounting=true

systemctl daemon-reload
systemctl restart myapp

# 验证配置
systemctl show myapp | grep Memory

MemoryHigh是软限制，超过此值时内核开始回收该组页面缓存，触发更积极回收但不杀进程。MemoryMax是硬限制，超过时触发该组内OOM Killer，仅杀组内进程而非系统全局进程。

容器环境内存限制与OOM行为分析

# Docker容器限制2GB内存和1GB swap
docker run -d \
  --name myapp \
  --memory=2g \
  --memory-swap=3g \
  --memory-reservation=1800m \
  myapp:latest

# 验证cgroups配置
docker inspect myapp | grep -A5 Memory

容器内存超过–memory限制时，容器内OOM Killer触发，杀掉容器内占用最大的进程而非宿主机进程。容器不会自动退出，除非被杀的是PID 1的主进程。

OOM事件监控与告警配置

# 查看系统级别OOM发生次数
grep oom /proc/vmstat

# 查看dmesg中的OOM记录
dmesg -T | grep -i "out of memory\|killed process"

# cgroups v2事件通知
cat /sys/fs/cgroup/app/myapp/memory.events
# oom 2
# oom_kill 1

配合inotifywait实现自动化监控告警：

inotifywait -m -e modify /sys/fs/cgroup/app/myapp/memory.events |
while read path event file; do
    oom_count=$(grep "^oom " /sys/fs/cgroup/app/myapp/memory.events | awk "{print \$2}")
    if [ "$oom_count" -gt 0 ]; then
        curl -s -X POST "https://alert.example.com/api/notify" \
          -d "message=myapp cgroup OOM triggered, count=$oom_count"
    fi
done

常见内存问题诊断与调优建议

使用smem工具按PSS排序定位内存消耗大户：smem -t -k -s pss | tail -20。调整vm.swappiness参数控制系统使用swap倾向（范围0-100，默认60），数据库服务器建议设为10-20减少swap使用。配置内核在OOM时记录所有进程内存信息：echo 1 > /proc/sys/vm/oom_dump_tasks。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linuxoomkiller-nei-cun-hui-shou-chu-fa-ji-zhi-yu-cgroups-zi/

小编

LoRA低秩适配微调大模型原理与PEFT参数高效配置实战

上一篇 9小时前

Jaeger分布式链路追踪系统部署与OpenTelemetry数据采集配置实战

下一篇 9小时前

Linux OOM Killer内存回收触发机制与cgroups资源限制配置实战

小编 • 9小时前 • 服务器

OOM Killer触发路径与内核内存分配流程

cat /proc/sys/vm/overcommit_memory
# 0: 启发式判断，默认值
# 1: 总是允许overcommit
# 2: 严格模式，commit总量不超过swap+ratio*RAM

OOM Score评分算法与进程选择策略

# 保护关键进程，降低被杀概率（范围-1000到1000）
echo -500 > /proc/$(pidof nginx)/oom_score_adj

# 确保某进程优先被杀
echo 500 > /proc/$(pidof some_worker)/oom_score_adj

oom_score_adj=-1000时该进程永不被OOM Killer选中，但可能导致其他进程被杀。生产环境对MySQL、Redis等核心服务设置-500到-900的值。

cgroups v2内存限制配置与层次结构

cgroups v2采用单一层级结构，所有控制器挂载在同一目录下。配置步骤：

# 创建应用控制组
mkdir -p /sys/fs/cgroup/app/myapp

# 设置内存上限为2GB
echo 2147483648 > /sys/fs/cgroup/app/myapp/memory.max

# 设置swap上限为1GB
echo 1073741824 > /sys/fs/cgroup/app/myapp/memory.swap.max

# 启用内存控制器
echo "+memory" > /sys/fs/cgroup/app/cgroup.subtree_control

# 将进程加入控制组
echo $(pidof myapp) > /sys/fs/cgroup/app/myapp/cgroup.procs

systemd集成cgroups内存限制配置

生产环境通过systemd管理服务，可直接在unit文件中配置资源限制：

# /etc/systemd/system/myapp.service
[Service]
ExecStart=/usr/bin/myapp
MemoryMax=2G
MemoryHigh=1800M
MemorySwapMax=1G
MemoryAccounting=true

systemctl daemon-reload
systemctl restart myapp

# 验证配置
systemctl show myapp | grep Memory

容器环境内存限制与OOM行为分析

# Docker容器限制2GB内存和1GB swap
docker run -d \
  --name myapp \
  --memory=2g \
  --memory-swap=3g \
  --memory-reservation=1800m \
  myapp:latest

# 验证cgroups配置
docker inspect myapp | grep -A5 Memory

容器内存超过–memory限制时，容器内OOM Killer触发，杀掉容器内占用最大的进程而非宿主机进程。容器不会自动退出，除非被杀的是PID 1的主进程。

OOM事件监控与告警配置

# 查看系统级别OOM发生次数
grep oom /proc/vmstat

# 查看dmesg中的OOM记录
dmesg -T | grep -i "out of memory\|killed process"

# cgroups v2事件通知
cat /sys/fs/cgroup/app/myapp/memory.events
# oom 2
# oom_kill 1

配合inotifywait实现自动化监控告警：

inotifywait -m -e modify /sys/fs/cgroup/app/myapp/memory.events |
while read path event file; do
    oom_count=$(grep "^oom " /sys/fs/cgroup/app/myapp/memory.events | awk "{print \$2}")
    if [ "$oom_count" -gt 0 ]; then
        curl -s -X POST "https://alert.example.com/api/notify" \
          -d "message=myapp cgroup OOM triggered, count=$oom_count"
    fi
done

常见内存问题诊断与调优建议

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linuxoomkiller-nei-cun-hui-shou-chu-fa-ji-zhi-yu-cgroups-zi/

cgroups资源限制 Linux内存管理 OOM Killer

小编

LoRA低秩适配微调大模型原理与PEFT参数高效配置实战

上一篇 9小时前

Jaeger分布式链路追踪系统部署与OpenTelemetry数据采集配置实战

下一篇 9小时前

Linux OOM Killer内存回收触发机制与cgroups资源限制配置实战

OOM Killer触发路径与内核内存分配流程

OOM Score评分算法与进程选择策略

cgroups v2内存限制配置与层次结构

systemd集成cgroups内存限制配置

容器环境内存限制与OOM行为分析

OOM事件监控与告警配置

常见内存问题诊断与调优建议

相关推荐

Linux OOM Killer内存回收触发机制与cgroups资源限制配置实战

OOM Killer触发路径与内核内存分配流程

OOM Score评分算法与进程选择策略

cgroups v2内存限制配置与层次结构

systemd集成cgroups内存限制配置

容器环境内存限制与OOM行为分析

OOM事件监控与告警配置

常见内存问题诊断与调优建议

相关推荐