Linux OOM killer机制介绍

最新推荐文章于 2024-06-09 14:53:56 发布
最新推荐文章于 2024-06-09 14:53:56 发布
阅读量1.4w 收藏 49
点赞数 4
分类专栏： Linux内核
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/run_for_belief/article/details/83446344
版权

1. 概念描述

Linux内核内存管理使用OOM killer（Out-Of-Memory killer）机制，在系统内存不足时，选择性杀死一些进程以释放内存，以使系统继续运行。

2. OOM killer产生的原因

2.1 malloc 内存分配

By default, Linux follows an optimistic memory allocation strategy.
This means that when malloc() returns non-NULL there is no guarantee that the memory really is available. This is a really bad bug. In case it turns out that the system is out of memory, one or more processes will be killed by the infamous OOM killer.

如上为malloc的manpage节选，说明malloc返回非空指针并不代表指向内存就是可用的，而当系统没有内存时，会通过杀死进程来腾出内存。

2.2 Memory Overcommit

此机制是指操作系统承诺给进程的内存大小超过实际可用物理内存。按照常规理解，内存分配有多少就分配多少，再申请就返回失败。但实际上这种策略是有些浪费内存，因为进程实际使用到的内存往往比申请的内存少。
按照Linux的算法，物理内存页的分配发生在使用瞬间，而不是在申请瞬间。overcommit针对 的也是内存申请，而不是内存分配。
Linux是允许memory overcommit的，即当申请的内存超过分配物理内存一定程度内，仍然可以申请成功。当实际使用时超过可分配物理内存时，利用OOM机制挑选一个进程出来杀死，以释放部分内存，如若不够则继续杀死进程，也可以配置内核参数panic_on_oom进行自动重启系统。

3. 虚拟内存分配

3.1 影响参数

3.1.1 overcommit_memory

用以控制内核的overcommit策略开关。

可选值含义
OVERCOMMIT_GUESS(0)视情况允许overcommit。系统在为应用进程分配虚拟地址空间时，会判断当前申请的虚拟地址空间大小是否超过剩余内存大小，如果超过，则虚拟地址空间分配失败。
OVERCOMMIT_ALWAYS(1)总是允许overcommit。系统在为应用进程分配虚拟地址空间时，完全不进行限制，避免了fork可能产生的失败，但由于malloc是先分配虚拟地址空间，而后通过异常陷入内核分配真正的物理内存，在内存不足的情况下，完全屏蔽了应用进程对系统内存状态的感知，即malloc总是能成功，但内存不足时会引起系统OOM杀进程。
OVERCOMMIT_NEVER(2)禁止overcommit，根据系统内存状态确定虚拟地址空间上限。然而很多情况下，进程的虚拟地址空间占用远大于其实际占用的物理内存，这样一旦内存使用量上去以后，对于一些动态产生的进程(需要复制父进程地址空间)则很容易创建失败，如果业务过程没有过多的这种动态申请内存或者创建子进程，则影响不大，否则会产生比较大的影响

3.1.2 overcommit_ratio

用以确定系统可申请内存大小，仅在禁止overcommit时生效。
可申请内存 = （总的物理内存 – huge页内存）* overcommit_ratio/100 + 交换分区大小。

3.1.3 admin_reserve_kbytes

系统为拥有cap_sys_admin权限用户预留的空闲内存大小。默认为3%的free pages与8MB中较小的值，以便管理员登录和杀死进程。

3.1.4 user_reserve_kbytes

系统为普通用户预留的空闲内存大小，仅在禁止overcommit时生效，默认为3%的free pages与128MB中的较小值，以便用户登录和杀死进程。

3.1.5 CommitLimit 和 Commited_AS

/proc/meminfo信息，禁止禁止overcommit时生效。

参数名称含义
CommitLimit可申请内存 =（总的物理内存 – huge页内存）* overcommit_ratio /100 + 交换分区大小。
Commited_AS当前已申请内存。

3.2 内存充足判断

用户空间分配内存时，内核都会调用__vm_enough_memory ()(mm/mmap.c) 来验证虚拟内存是否足够进行分配。

  1. 总是允许overcommit，直接返回0，表示内存充足。
  2. 视情况判断overcommit
    空闲内存free page计算，如下。
+=global_page_state(NR_FREE_PAGES)
位于Buddy system的free list中，没有任何开销可以使用；

+=global_page_state(NR_FILE_PAGES)
page cache，为加快用户空间读写文件性能使用，可以直接操作磁盘，可视为free。

-=global_page_state(NR_SHMEM)
用于进程间share memory机制，不能清除free，因此要减去。

+= get_nr_swap_pages()
swap file或swap device上的空闲page frame，由于其可作为anonymous page做腾挪，即把使用中的page frame swap out到swap page上，也算作free，开销较大。

+= global_page_state(NR_SLAB_RECLAIMABLE)
slab已标记可回收的page frame。

-= totalreserve_pages
系统运行预留的page，若小于等于此直接返回内存不足，否则减去预留。

-= sysctl_admin_reserve_kbytes >> (PAGE_SHIFT - 10)
对于普通进程，保留一定的free page，以保证管理员可以登录并执行恢复操作。

free > pages，若空闲内存大于申请内存，返回内存充足，否则返回内存不足。
  1. 禁止overcommit
    可申请内存allowed阈值计算，如下。
+=(totalram_pages - hugetlb_total_pages()) * sysctl_overcommit_ratio / 100。

-= sysctl_admin_reserve_kbytes >> (PAGE_SHIFT - 10)
对于普通用户进程，保留一定的free page，以保证管理员可以登录并执行恢复操作。

-= min(mm->total_vm / 32, sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10)
用户态进程，需预留内存保证登录并执行恢复操作。

percpu_counter_read_positive(&vm_committed_as) < allowed
已申请内存小于允许内存，返回内存充足，否则返回内存不足。

4. 物理内存分配

4.1 影响参数

4.1.1 min_free_kbytes

  1. 代表系统所保留空闲内存的最低限。
    min_free_kbytes = sqrt(lowmem_kbytes * 16) = 4 * sqrt(lowmem_kbytes)
    最小为128K，最大为64M ，lowmem_kbytes可认为是系统内存大小。
  2. 用于计算内存回收水印（zone_watermark）。
  1. zone watermark计算方法（每个zone各有一套watermark参数）
watermark[min] = per_zone_min_free_pages （min_free_kbytes换算为page单位）
watermark[low] = watermark[min] * 5 / 4
watermark[high] = watermark[min] * 3 / 2
不同内存水印跨度：per_zone_min_free_pages * 1/4，即跟内存大小成开方关系。
  1. zone_watermark作用
    在系统空闲内存低于low时，开始启动内核线程kswapd进行内存回收，直到该zone的空闲内存数量达到high后停止回收。
    如果上层申请内存的速度太快，导致空闲内存降至min后，内核就会进行direct reclaim（直接回收），即直接在应用程序的进程上下文中进行回收，再用回收上来的空闲页满足内存申请，因此实际会阻塞应用程序，带来一定的响应延迟，而且可能会触发系统OOM。
    min以下的内存属于系统自留内存，用以满足特殊使用，不会给用户态的普通申请来用。
  1. min_free_kbytes大小的影响
    min_free_kbytes越大，watermark越高，同时三个线之间的buffer量也会相应增加。这意味着会较早的启动kswapd进行回收，且会回收上来较多的内存（直至watermark[high]才会停止），导致系统预留过多空闲内存，一定程度上降低了应用程序可使用的内存。极端情况下设置为接近内存大小时，留给应用程序的内存就会太少而可能频繁导致OOM的发生。
    min_free_kbytes过小，则会导致系统预留内存过小。kswapd回收的过程中也会有少量的内存分配行为（会设上PF_MEMALLOC）标志，这个标志会允许kswapd使用预留内存；另外一种情况是被OOM选中杀死的进程在退出过程中，如果需要申请内存也可以使用预留部分。这两种情况下使用预留内存可以避免系统进入deadlock状态。

4.1.2 lowmem_reserve_ratio

  1. 各个zone之间进行的内存预留
    防止高端zone在没内存的情况下过度使用低端zone的内存资源。低端内存比较小，且有一定的特殊作用比如发生DMA时只能分配DMA zone的低端内存，因此需要在尽量可以使用高端内存时 而不使用低端内存，同时防止高端内存分配不足的时候抢占稀有的低端内存。此参数可以调整内核对于lower zone的保护力度。
  2. 计算及使用方法
    lowmem_reserve_ratio是一个数组，可以通过以下命令查看。
cat /proc/sys/vm/lowmem_reserve_ratio
256     32

数组的长度=内存zone数量 - 1，其中每个数并不是绝对值，而是一个比例，代表1/256或1/32。zone[i] 的 protection[j] 计算规则如下。

(i < j):
zone[i]->protection[j] = (total sums of present_pages from zone[i+1] to zone[j] on the node)/ lowmem_reserve_ratio[i];
(i = j):
  (should not be protected. = 0;
(i > j):
  (not necessary, but looks 0)

计算结果可通过以下命令查看。

cat /proc/zoneinfo
Node 0, zone      DMA
  pages free     3718
        min      335
        low      418
        high     502
……
        protection: (0, 3399, 3399)
……
Node 0, zone   Normal
  pages free     13719
        min      2224
        low      2780
        high     3336
……
        protection: (0, 0, 0)
……

在进行内存分配时，这些预留页数和watermark相加来一起决定现在是满足分配请求，若是认为空闲内存量过低需要启动回收。例如，如果一个normal区的页申请来试图分配DMA区的内存，且现在使用的判断标准是watermark[low]时，内核计算出 page_free = 3718，而watermark + protection[1] = 418 + 3399 = 3817 > page_free，则认为空闲内存太少而不予以分配。如果分配请求本就来自DMA zone，则 protection[0] = 0会被使用，而满足分配申请。

4.2 内存充足判断

在执行伙伴系统算法分配页框以前,需要调用zone_watermark_ok()(mm/page_alloc.c)判断当前内存区中的页框数目是否满足水印要求。若不满足要求，则会分配失败，最终导致OOM。

min = mark; 根据水印设置最小值
if (alloc_flags & ALLOC_HIGH) min -= min / 2; 若需求比较迫切，则放宽限制
if (alloc_flags & ALLOC_HARDER) min -= min / 4; 若需求很迫切，则进一步放宽限制

free_pages = zone_page_state(z, NR_FREE_PAGES); 计算空闲页面数量
free_pages -= (1 << order) - 1;
判断的是分配出去2^order个page之后的free pages是否满足水印要求

free_pages <= min + z->lowmem_reserve[classzone_idx]; 
若free pages已经不大于保留内存和min之和，说明不满足watermark要求

遍历buddy中比请求order小的所有order，检查free pages是否满足watermark要求。
for (o = 0; o < order; o++) {
  每个循环当中，先减去当前order的free pages
  free_pages -= z->free_area[o].nr_free << o;
  
  将min，即判断标准作相应的缩小
  min >>= 1;
  
  比较处理后的free pages和min，看是否满足watermark要求
  if (free_pages <= min)
	return false;
}

简单来看分配完后只要剩余的页数大于水位，就可以安然返回。但是伙伴系统不仅考虑剩余也总数，还要考虑内存碎片情况，上述检查循环其实是为了保证位于高阶和低阶的页大体均衡。尤其是free_pages比较少，正好位于水印附近的时候。

4.3 OOM 发生的影响因素

根据上述说明，可以总结影响OOM发生的因素，请求分配的order大小，请求分配发生的zone，zone的水印大小，内存碎片化程度。

5. OOM killer 调试参数

5.1 panic_on_oom

用以控制内核OOM时，是否触发panic的开关。

可选值含义
0不触发panic。
1如果是因为mempolicy、cpuset、memcg等限制未分配到内存，实际还有内存那么不触发panic，否则触发panic。
2直接触发panic。

5.2 oom_dump_tasks

用以控制内核OOM时，是否调用dump_tasks来打印所有task的内存状况。

可选值含义
0不会调用打印（进程数量很多时，逐一打印可能导致性能问题）。
1在如下情况会执行打印：a.由于OOM导致kernel panic，b.没有找到合适的bad进程，c.找到合适进程杀死时。

5.3 oom_kill_allocating_task

用以控制内核OOM时，是否优先杀死触发OOM的进程。

可选值含义
0选择最“坏”进程杀死。
1若触发OOM进程是用户空间进程、不是unkillable task（如init进程），未设定oom_score_adj阻止kill该进程，则直接杀死此进程。

5.4 oom_score_adj

进程得分相关参数，每个进程独有。

参数名称含义
oom_score进程oom_badness计算得分，为只读参数。
oom_score_adj计算进程得分时的调整值。取值范围是-1000～1000，0表示不调整得分，负值表示在实际打分值上减去一个折扣，正值表示要惩罚该进程增加得分。
oom_adj旧的计算进程得分时的调整值，实际使用时会转换为oom_score_adj。

6. OOM killer 选择算法

在这里插入图片描述

北方木易
关注
  • 4
    点赞
  • 踩
  • 49
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
MySQL OOM 系统二 OOM Killer
09-10
综上所述，Linux的OOM Killer机制通过复杂的算法判断哪些进程应该被终止，以应对系统内存不足的危机。理解这一机制对于管理和优化在资源有限环境下的服务，如MySQL数据库，至关重要。合理配置系统资源和优化进程行为...
Linux开发心得总结5 - Linux下OOM Killer机制详解
ynttmp的专栏
03-01 1306
Linux下面有个特性叫OOM killer（Out Of Memory killer），这个东西会在系统内存耗尽的情况下跳出来，选择性的干掉一些进程以求释放一些内存。相信广大从事Linux服务端编程的农民工兄弟们或多或少遇到过（人在江湖漂，哪有不挨刀啊）。典型的情况是：某天机器突然登不上了，能ping通，但是ssh死活连不了。原因是sshd进程被OOM killer干掉了（泪流满面）。重启机器后
OOM Killer机制
weixin_48101150的博客
05-24 4062
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
工作学习笔记-oom killer详解
最新发布
keeprunper的博客
06-09 484
本篇文章一起探讨下oom-killer相关问题先简单记录下oom的一些参数信息，oom相关问题持续更新。
高级OS(六） - 用户态进程管理的方方面面
zxq997997的博客
03-10 1123
高级OS(六） - 用户态进程管理的方方面面一.题目二.解答1.监控进程的状态，ps, top,kill命令的使用，以及硬中断和软中断的理解，通过查看/proc/softirqs来观察中断的运行情况。2.进程优先级，top/ps，nice/renice命令的使用（4个命令都用一下）3.企业案例，Linux假死是怎么回事，深刻理解fork()是怎么回事，oom killer是干什么？出现假死情况怎么办？如何分析故障？截图说明4.后台进程管理，安装screen和nohup命令，并使用，截图，并给出心得体会5.系
Linux 下的 OOM Killer理解Out of memory: Kill process
u014644574的博客
10-19 1264
Linux 下的 OOM Killer理解Out of memory: Kill process
Linux内核OOM机制的详细分析
weixin_34227447的博客
08-09 645
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。典型的情况是：某天一台机器突然ssh远程登录不了，但能ping通，说明不是网络的故障，原因是sshd进程被OOM killer杀掉了（多次遇到这样的假死状况）。重启机器后查看系统日志/var/log/mes...
Linux系统的OOM Killer处理机制.docx
09-26
Linux系统的OOM Killer处理机制 Linux系统的OOM（Out of Memory）Killer处理机制是一种内核机制，用于在系统内存不足时杀掉某个进程以腾出内存留给系统用，不致于让系统立刻崩溃。OOM Killer的触发条件是系统内存...
有关OOM KILLER的一些理解
04-06
OOM Killer，全称为Out of Memory Killer，是Linux内核中的一种机制，用于处理系统内存不足的情况。当系统内存耗尽时，为了避免整个系统的崩溃，OOM Killer会选择并终止一些进程来释放内存，从而确保系统的稳定运行...
MySQL Slave 触发 oom-killer解决方法
09-10
在这种情况下，Linux内核会启动oom-killer机制来杀死消耗内存最多的进程，以保护系统的稳定性。针对这个问题，我们可以从多个角度进行排查和解决： 1. **检查InnoDB Buffer Pool**： - `innodb_buffer_pool_size` ...
heart_oom_protect:Erlang库可保护心脏免受Linux内核的OOM Killer的杀害
05-13
当Linux系统面临内存不足的压力时，内核会启动一个称为“Out-of-Memory (OOM) Killer”的机制来防止系统崩溃。然而，OOM Killer可能会选择终止重要的进程，包括Erlang应用程序。针对这种情况，有一个名为“heart_oom...
Linux内核OOM killer机制
热门推荐
让我思考一下
08-29 3万+
程序运行了一段时间，有2个进程挂掉了，正常情况下进程不会主动挂掉，简单分析后认为可能是运行时某段时间内存占用过大，系统内存不足导致触发了Linux操作系统OOM killer机制，将运行中的进程杀掉了。 Linux 内核有个机制叫OOM killer(Out Of Memory killer)，该机制会监控那些占用内存过大，尤其是瞬间占用内存很快的进程，然后防止内存耗尽而自动把该进程杀掉。...
linux杀死进程机制,Linux的oom killer机制学习
weixin_35011300的博客
04-28 464
我们项目在跑大量用户时，经常会出现进程死掉的情况，dmsg看到是oom机制杀掉了，刚好乘机学习一下linux的oom机制。OOM(Out of Memory)机制是Linux内核的自我保护机制，当系统内存不够使用时会触发，系统会挑选一个占用内存较多的进程来杀掉释放内存。Linux内核允许程序申请比系统可用内存更多的内存(malloc),这个特性称为overcommit，这样做的目的是出于优化系统的...
查看进程是否是由于linux OOM killer机制杀死的方法
top_explore的博客
08-01 1477
问题 如果进程突然被杀死没有应用日志，而且进程占用内存过高，考虑是否是由于linux OOM killer机制杀死的。 原因 linux内核有个OOM Killer机制会在内存不够分配的时候触发，选择性的杀死一些内存占用最高的进程腾出内存空间，保证系统正常运行。详细请看https://blog.csdn.net/top_explore/article/details/107733974。 确定问题 查看linux内核日志： grep "Out of memory" /var/log/messa
Linux 的 OOM Killer 机制分析
weixin_39355187的博客
05-25 378
Linux 的 OOM Killer 机制分析 按需分配物理页面 　　很多情况下，一个进程会申请一块很大的内存，但只是用到其中的一小部分。为了避免内存的浪费，在分配页面时，Linux 采用的是按需分配物理页面的方式。譬如说，某个进程调用malloc()申请了一块小内存，这时内核会分配一个虚拟页面，但这个页面不会映射到实际的物理页面。 　　从图中可以看到，当程序首次访问这个虚拟页面时，会触发一个缺页异常 (page fault)。这时内核会分配一个物理页面，让虚拟页面映射到这个物理页面，同时.
Linux OOM Killer机制 以及防止被OOM Killer杀死的方法
top_explore的博客
08-01 8333
Overcommit Linux内核根据应用程序的要求分配内存，通常来说应用程序分配了内存但是并没有实际全部使用，为了提高内存使用率，这部分没用的内存可以提供给其他的应用程序来使用，但是这部分内存是属于每个进程的，内核直接回收利用的话比较麻烦，所以内核采用一种过度分配内存（over-commit memory）的办法来间接利用这部分“空闲”的内存，提高整体内存的使用效率。这种过度分配内存的策略就叫内存分配策略。在系统中由两个属性决定，在系统中的默认配置为： [root@node01 redis-5.0
Linux系统OOM killer机制详解
weixin_30340353的博客
08-01 351
介绍： Linux下面有个特性叫OOM killer（Out Of Memory killer），会在系统内存耗尽的情况下出现，选择性的干掉一些进程以求释放一些内存。广大从事Linux方面的IT农民工兄弟或多或少都有遇到过吧。 现象： 主机SSH突然无法连接，主机重启要过很久，重启后主机正常，登录查看日志信息，会有大量的 " Out of Memory: Killed...
Nginx 假性内存泄露
Network/Storage/Linux Kernel
12-27 2951
Nginx 假性内存泄露 Nginx在使用中，发现其使用的VSZ和RSS都在不断变大，查看新增的代码，没有找到内存泄露的地方，ngx_palloc和ngx_pfree都是对称调用的。 Nginx 内存池机制 使用Nginx开发过的都知道，在Nginx里面普遍使用ngx_palloc/ngx_pnalloc申请内存，其中入参有一个pool，它是从ngx_create_pool获得的一个对象，改函数入...
oom killer
10-17
oom killer 是 Linux 操作系统中的一个机制，用于在系统内存不足时杀死占用内存较多的进程，以释放内存。当系统内存不足时，oom killer 会根据一定的算法选择一个进程杀死，以释放内存。通常情况下，oom killer 会...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值