oom-killer

最新推荐文章于 2025-07-18 11:37:35 发布
最新推荐文章于 2025-07-18 11:37:35 发布
阅读量2.6k 收藏
点赞数
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/luckywang1103/article/details/48686219
本文深入探讨了Linux系统在内存资源紧张时如何触发oom-killer机制，详细解析了其工作原理、内核代码位置、以及如何通过配置/调整参数避免不必要的进程被kill。包括oom-killer如何选择并kill占用内存较高的进程，以及如何通过配置/调整进程的oom_adj和oom_score_adj来影响被kill的风险。

内存不够时系统会启动oom-killer
~ # xxx_test 192.168.1.29 192.168.1.71
rtl8168: eth0: link up
info [create_socket_srv:354]: listening on port : 6789
info [listen_func:304]: connection[4] : 192.168.1.71:43786
[process_cmd:365]: $taes #cd
ft2_test invoked oom-killer: gfp_mask=0x200da, order=0, oom_score_adj=0
CPU: 0 PID: 107 Comm: ft2_test Not tainted 3.10.27+ #401
Stack : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 8efc9b98
…

Call Trace:[<800144f4>] 0x800144f4
[<800144f4>] 0x800144f4
[<80446c20>] 0x80446c20
[<80189f04>] 0x80189f04
[<80066744>] 0x80066744
[<80028420>] 0x80028420
[<800665e8>] 0x800665e8
[<80066568>] 0x80066568
[<80066ff0>] 0x80066ff0
[<8006a648>] 0x8006a648
[<8018ed24>] 0x8018ed24
[<8007ba94>] 0x8007ba94
[<8007e370>] 0x8007e370
[<8007e040>] 0x8007e040
[<800804a8>] 0x800804a8
[<8007bc88>] 0x8007bc88
[<80017428>] 0x80017428
[<800809c4>] 0x800809c4
[<8018add4>] 0x8018add4
[<80073cdc>] 0x80073cdc
[<8007f76c>] 0x8007f76c
[<8018add4>] 0x8018add4
[<8007eeac>] 0x8007eeac
[<80011ba4>] 0x80011ba4
[<8018eb98>] 0x8018eb98

Mem-Info:
Normal per-cpu:
CPU 0: hi: 90, btch: 15 usd: 33
active_anon:42496 inactive_anon:0 isolated_anon:0
active_file:0 inactive_file:2 isolated_file:0
unevictable:958 dirty:0 writeback:0 unstable:0
free:427 slab_reclaimable:163 slab_unreclaimable:343
mapped:156 shmem:0 pagetables:54 bounce:0
free_cma:0
Normal free:1708kB min:1728kB low:2160kB high:2592kB active_anon:169984kB inactive_anon:0kB active_file:0kB inactive_file:8kB unevictable:3832kB isolated(anon):0kB isolated(file):0kB present:262144kB managed:187256kB mlocked:0kB dirty:0kB writeback:0kB mapped:624kB shmem:0kB slab_reclaimable:652kB slab_unreclaimable:1372kB kernel_stack:272kB pagetables:216kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:46 all_unreclaimable? yes
lowmem_reserve[]: 0 0
Normal: 1*4kB (M) 1*8kB (U) 2*16kB (UM) 0*32kB 2*64kB (UM) 0*128kB 0*256kB 1*512kB (M) 1*1024kB (M) 0*2048kB 0*4096kB = 1708kB
960 total pagecache pages
65536 pages RAM
18347 pages reserved
270083 pages shared
44021 pages non-shared
[ pid ] uid tgid total_vm rss nr_ptes swapents oom_score_adj name
[ 84] 0 84 214 96 3 0 0 sh
[ 96] 0 96 46273 42577 48 0 0 ft2_test
Out of memory: Kill process 96 (ft2_test) score 873 or sacrifice child
Killed process 96 (ft2_test) total-vm:185092kB, anon-rss:169872kB, file-rss:436kB
Killed

oom-killer
oom-killer相关的内核代码位置在mm/oom-kill.c
oom-killer会在内存紧张的时候，依次kill内存占用较高的进程，发送signal 15(SIGTERM)，并在/var/log/message中进行记录。

Oom-kill杀死进程的机制
/proc/vm/oom_adj 表示该pid进程被oom killer杀掉的权重，在[-17, 15]之间，越高的权重，意味着越有可能被oom-killer选中，-17表示禁止被kill掉。
/proc/vm/oom_score 当前进程被kill的分数，越高的分数，意味着越有可能被kill

Linux实战-2：内存不足触发Linux OOM-killer机制分析
zhuyunier的博客
12-13 1万+
启动我们的程序长时间拉流一段时间，系统内存不足导致触发linux的OOM killer保护机制，kill掉内存占用较高的HPC03C进程 ，打印如下： [16321.605050] HPC03C invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 [16321.645746] CPU: 0 PID: 119 Comm: HP...
Java Invoked OOM-Killer - OOM不一定是来自于java heap
gleethu的专栏
01-19 4481
Java Invoked OOM-Killer - OOM不一定是只来自于java heap什么是OOM-killer解决过程总结 什么是OOM-killer 这里有关于oom-killer的介绍：https://medium.com/@rchint/analyzing-issues-caused-by-oom-killer-2933a13e3e09。我这里的场景是我的tomcat app 经常被...
java oom-killer_Tomcat崩溃kernel: java invoked oom-killer: gfp_mask
weixin_39662432的博客
02-24 586
场景Jan 16 03:03:57 host-172-16-61-102 vm-agent: network-posix.c GetIpv4VifIp 1201 : failed to GetIpv4VifGatewayJan 16 03:03:57 host-172-16-61-102 vm-agent: popen errorJan 16 03:03:58 host-172-16-61-102...
oom killer理解和日志分析
ss810540895的博客
02-08 1370
是Linux内核设计的一种机制，在内存不足的时候，选择一个占用内存较大的进程并kill掉这个进程，以满足内存申请的需求（内存不足的时候该怎么办，其实是个两难的事情，oom killer算是提供了一种方案吧）内存不足申请失败的细节都分析清楚了，剩下的问题就是为什么java会申请这么多内存(5.8G)，明明-Xmx配置的是4G，加上PermSize，也就最多4.3G。
Linux内存管理——OOM Killer
最新发布
m0_72426445的博客
07-18 1107
OOMKiller是Linux内核的内存保护机制，当系统内存耗尽时，它会终止高内存消耗进程以释放内存。其选择策略基于进程的OOM得分，通过调整可控制进程被杀优先级。理解OOMKiller有助于优化内存管理，保护关键进程，提高系统稳定性。
OOM killer 杀死进程导致进程异常退出的临时解决方案
jinking01的专栏
08-27 2768
临时解决oom killer杀死进程导致进程异常退出的问题。
Linux OOM killer
weixin_33800593的博客
02-06 389
作为Linux下的程序员，有时不得不面对一个问题，那就是系统内存被用光了，这时当进程再向内核申请内存时，内核会怎么办呢？程序里面调用的malloc函数会返回null吗？ 为了处理内存不足时的问题，Linux内核发明了一种机制，叫OOM(Out Of Memory) killer，通过配置它可以控制内存不足时内核的行为。 OOM kille...
MySQL Slave 触发 oom-killer解决方法
01-21
Mar 9 11:29:16 xxxxxx kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 Mar 9 11:29:16 xxxxxx kernel: mysqld cpuset=/ mems_allowed=0 Mar 9 11:29:16 x
OOM Killer机制
weixin_48101150的博客
05-24 4379
oom killer 概念 oom killer是内核设计的一种机制，在内存不足时选择一个占用内存较大的进程把他杀死，释放这一部分内存来满足内存请求的的需求。 oom（out of memory） OOM(Out of Memory)指Linux在无可用内存时的一个最后策略。当系统中可用内存过少时，OOM killer会选择kill某些进程，来释放这些进程所占用的内存。 void out_of_memory(int gfp_mask) { struct mm_struct *mm = NULL; tas
Linux OOM-killer机制说明
xiejianjun417的专栏
04-15 4208
1.什么是OOM-killer oom_killer（out of memory killer）是Linux内核的一种内存管理机制，在系统可用内存较少的情况下，内核为保证系统还能够继续运行下去，会选择杀掉一些进程释放掉一些内存。通常oom_killer的触发流程是：进程A想要分配物理内存（通常是读写内存）->触发缺页异常->内核去分配物理内存->物理内存不足，触发OOM。 1......
工作学习笔记-oom killer详解
keeprunper的博客
06-09 1646
本篇文章一起探讨下oom-killer相关问题先简单记录下oom的一些参数信息，oom相关问题持续更新。
oom killer 详解
weixin_34186128的博客
06-26 3637
一、oom killer理解和日志分析:知识储备 oom killer日志分析，这是前篇，准备一些基础知识 带着问题看： 1.什么是oom killer 是Linux内核设计的一种机制，在内存不足的时候，选择一个占用内存较大的进程并kill掉这个进程，以满足内存申请的需求（内存不足的时候该怎么办，其实是个两难的事情，oom killer算是提供了一种方案吧） 2.在什么时候触发？...
【Linux】进程OOM-kill 监控和规避
康师傅没有眼泪
07-05 3766
在Linux系统内存将要用完的情况下，OOM-killer进程会遍历当前机器上的所有进程，按照进程所占内存的大小和用户打分(oom_score_adj)对进程进行打分（占用内存越大，分数越高），然后挑选出分数最高的进程将其kill掉。在工作过程中，你可能会遇到过这种情况，程序在运行一段时间之后突然挂掉，在你保证程序在正常情况下不会挂掉的情况下，程序挂掉的原因可能是在你的程序运行过程中，有一段时间你的程序运行内存过大，而此时系统物理内存不足，导致系统触发OOM killer机制，将该进程kill。
Linux内存清道夫--OOM Killer
红笺小字
03-22 3768
OOM Killer作为linux系统中守护进程，主要在系统内存太低而不足以分配所需内存时工作。
Linux OOM Killer详解
抛物线的博客
08-06 1758
在Linux操作系统中，内存管理至关重要。当系统内存耗尽时，如果不采取措施，会导致系统崩溃。为了解决这个问题，Linux内核引入了一种保护机制——OOM Killer（Out-Of-Memory Killer）。当系统内存耗尽时，OOM Killer会选择并终止一些进程，以释放内存，确保系统继续运行。本博客将详细介绍OOM Killer的技术原理、工作机制，并通过实际场景举例说明其应用。Linux OOM Killer是一种重要的内存保护机制，在系统内存耗尽时通过终止进程来释放内存，确保系统继续运行。
副本技能-记录一次OOM的异常处理
汉风唐尚的博客
12-10 5174
问题定位 1.服务挂的现象出现！ 2.检查发现并未出现OOM的溢出DUMP文件产生 3.检查是否是被Linux系统给杀了 服务器环境查询步骤 服务启动脚本查看 // 查看Shell脚本 [vevor@v169 bmp-crm-manager]$ cat start.sh # 脚本内容如下 #!/bin/bash DATE=$(date +%Y%m%d) source /etc/profile DIR=/home/vevor/vevor-bmp-packages/bmp-crm-manager/ cd
linux内存回收(三）--OOM Killer
奇小葩
10-24 4719
当业务繁忙的服务器里，我们常常发现系统在非常大的内存压力情况下，触发了OOM Killer机制，OOM Killer机制是内存管理中在资源极端缺乏情况下一种迫不得已的进程终止机制，OOM Killer机制会根据算法选择并终止占用内存资源较多的进程，以便释放内存资源。本章的主要内容是了解OOM Killer是如何运转的。 1 触发过程 根据内存回收的流程，在慢速路径__alloc_pages_slowpath中，当反复尝试reclaim和compact后仍不成功，就会调用__alloc_pages_may_o
oom killer理解和日志分析:知识储备
chenliang0224的专栏
01-05 1370
oom killer日志分析，这是前篇，准备一些基础知识带着问题看：1.什么是oom killer是Linux内核设计的一种机制，在内存不足的时候，选择一个占用内存较大的进程并kill掉这个进程，以满足内存申请的需求（内存不足的时候该怎么办，其实是个两难的事情，oom killer算是提供了一种方案吧）2.在什么时候触发？前面说了，在内存不足的时候触发，主要牵涉到【linux的物理内存结构】和【overcommit机制】2.1 内存结构 node、zone、page、order。
Monitor invoked oom-killer: gfp_mask=0x7080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null), order=1, oom_score_adj=0
03-22
<think>嗯，用户遇到了一个系统提示：“Monitor invoked oom-killer: gfp_mask=0x7080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), nodemask=(null), order=1, oom_score_adj=0”，需要解释这个错误信息。首先，我要理解这个日志的含义。 首先，oom-killer是Linux内核在内存不足时触发的机制，用于终止进程以释放内存。用户看到的这条信息是系统在内存严重不足时，oom-killer被调用的记录。接下来需要拆解各个参数的意义。 gfp_mask=0x7080c0，这部分是内存分配标志的组合。GFP_KERNEL_ACCOUNT表示内核为某个进程分配内存并进行统计，可能用于cgroup等记账机制。__GFP_ZERO表示分配的内存会被初始化为零。组合起来，这次内存请求可能需要内核账户统计，并且需要清零的内存区域。 nodemask=(null)说明没有指定特定的NUMA节点，可以在所有节点分配内存。order=1表示请求分配2^1=2个连续的内存页，即8KB（假设页大小为4KB）。oom_score_adj=0说明触发oom-killer的进程的调整值为0，通常这个值越低，进程越不容易被杀死，但这里可能因为系统整体内存不足，即使调整值为0的进程也可能被终止。 接下来需要分析可能的原因。系统物理内存不足，或者存在内存泄漏导致内存耗尽。另外，虽然order=1看起来不大，但连续内存分配失败可能也是问题。还有cgroup的内存限制可能导致即使系统有空闲内存，特定cgroup中的进程也无法分配。 解决方案方面，需要检查内存使用情况，可以用free -h或top命令。检查内核日志dmesg获取更多OOM相关信息，找到被终止的进程。调整oom_score_adj可能预防问题，但需谨慎。增加系统内存或优化应用程序的内存使用也是根本方法。检查cgroup配置，确保没有不合理的内存限制。 用户可能需要具体的命令和步骤，比如如何查看内存，如何分析日志，如何调整参数。需要确保回答清晰，步骤明确，帮助用户逐步排查问题。同时提醒用户注意数据备份，避免在OOM发生时数据丢失。</think>这个日志信息是 Linux 系统在内存耗尽时触发的 `oom-killer` 机制的记录。以下是逐层解析和应对建议： --- ### 一、关键信息拆解 1. **`Monitor invoked omm-killer`** - 表示系统检测到内存不足（Out Of Memory），触发内核的 `oom-killer` 机制，该机制会强制终止某些进程以释放内存。 2. **`gfp_mask=0x7080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO)`** - `gfp_mask` 是内存分配的标志位组合： - `GFP_KERNEL_ACCOUNT`: 内核为进程分配内存时需进行会计统计（常用于 cgroup 内存控制）。 - `__GFP_ZERO`: 分配的内存需初始化为零值。 - 此标志组合表示内核正在尝试为某个进程分配需记账且清零的内存区域。 3. **`nodemask=(null)`** - 未指定 NUMA 节点（即允许在所有内存节点分配内存）。 4. **`order=1`** - 请求分配 $2^{\text{order}}$ 个连续物理页（通常页大小为 4KB，即申请 $2^1 \times 4\text{KB} = 8\text{KB}$ 连续内存）。 5. **`oom_score_adj=0`** - 触发 OOM 的进程的优先级调整值为 0（范围 -1000~1000，值越低越不易被终止）。 --- ### 二、可能原因 1. **系统物理内存不足** - 应用程序或内核模块消耗过多内存。 - 内存泄漏（如内核驱动或用户态进程未释放内存）。 2. **连续内存分配失败** - 尽管 `order=1` 请求的内存较小，但内核无法找到足够的连续物理页。 3. **cgroup 内存限制** - 若进程受 cgroup 限制，即使系统整体内存充足，进程也可能因 cgroup 配额耗尽触发 OOM。 --- ### 三、排查与解决步骤 #### 1. 检查内存使用情况 ```bash # 查看整体内存状态 free -h # 监控进程内存占用 top -o %MEM ``` #### 2. 分析 OOM 日志 ```bash # 查看完整内核日志（关注 OOM 前后的记录） dmesg | grep -i "oom-killer" dmesg | grep -i "killed process" ``` #### 3. 定位问题进程 - 日志中会记录被终止的进程名和 PID，例如： `Killed process 1234 (your_process)` #### 4. 调整 OOM 优先级（谨慎操作） ```bash # 降低某进程被终止的概率（值越小越安全） echo -100 > /proc/<PID>/oom_score_adj ``` #### 5. 优化内存使用 - 升级物理内存。 - 优化应用程序代码（减少内存泄漏，限制缓存大小）。 - 调整内核参数（如 `vm.overcommit_memory`）。 #### 6. 检查 cgroup 限制 ```bash # 若使用容器（如 Docker），检查内存限制 docker inspect <container_id> | grep -i "memory" ``` --- ### 四、典型场景示例 - **场景 1**：数据库服务（如 MySQL）因未配置内存上限，导致占用所有内存。 **解决**：在配置文件中限制 `innodb_buffer_pool_size`。 - **场景 2**：内核驱动存在内存泄漏。 **解决**：更新驱动或通过 `vmstat -s` 监控内核内存使用。 --- 若需进一步分析，请提供完整的 `dmesg` 日志或应用程序内存配置细节。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

luckywang1103

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值