背景

linux内核有个机制叫OOM killer(Out-Of-Memory killer)，当系统需要申请内存却申请不到时，OOM killer会检查当前进程中占用内存最大者，将其杀掉，腾出内存保障系统正常运行。

一般而言，一个应用的内存逐渐增加，肯定是不正常的，这个时候可认为该应用存在内存泄漏，当系统内存被占用到一定的时候，将会触发OOM，此时系统将会找一个最合适的进程杀掉，以释放内存。

系统如何查找最合适的进程杀掉此处不深入介绍，只介绍出现OOM时，现场如何分析。

另外补充一下，不一定是进程存在内存泄漏，可能是内核驱动、内存碎片化严重等问题都会触发OOM。

现场

在系统触发OOM时，都会有现场信息打印，例如下面的：

[41311.854276] udevd invoked oom-killer: gfp_mask=0x27080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=0, order=1, oom_score_adj=-1000
[41311.873871] COMPACTION is disabled!!!
[41311.878101] CPU: 0 PID: 1069 Comm: udevd Not tainted 4.9.191 #147
[41311.885079] Hardware name: arm
[41311.889103] [<c010d3cc>] (unwind_backtrace) from [<c010a51c>] (show_stack+0x10/0x14)
[41311.897984] [<c010a51c>] (show_stack) from [<c01b2be8>] (dump_header.constprop.4+0x7c/0x1c8)
[41311.907480] [<c01b2be8>] (dump_header.constprop.4) from [<c0176404>] (oom_kill_process+0xf0/0x4d0)
[41311.917732] [<c0176404>] (oom_kill_process) from [<c0176cac>] (out_of_memory+0x348/0x3f0)
[41311.927687] [<c0176cac>] (out_of_memory) from [<c017ae5c>] (__alloc_pages_nodemask+0x884/0x928)
[41311.937826] [<c017ae5c>] (__alloc_pages_nodemask) from [<c0116428>] (copy_process.part.3+0x160/0x1574)
[41311.948461] [<c0116428>] (copy_process.part.3) from [<c011798c>] (_do_fork+0xb0/0x358)
[41311.957436] [<c011798c>] (_do_fork) from [<c0117ca4>] (sys_fork+0x20/0x28)
[41311.966475] [<c0117ca4>] (sys_fork) from [<c0106bc0>] (ret_fast_syscall+0x0/0x54)
[41311.974953] Mem-Info:
[41311.977605] active_anon:1158 inactive_anon:25 isolated_anon:0
[41311.977605]  active_file:49363 inactive_file:59329 isolated_file:0
[41311.977605]  unevictable:0 dirty:1 writeback:0 unstable:0
[41311.977605]  slab_reclaimable:1446 slab_unreclaimable:1541
[41311.977605]  mapped:988 shmem:26 pagetables:53 bounce:0
[41311.977605]  free:2975 free_pcp:174 free_cma:0
[41312.014748] Node 0 active_anon:4632kB inactive_anon:100kB active_file:197452kB inactive_file:237316kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:3952kB dirty:4kB writeback:0kB shmem:104kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
[41312.044605] Normal free:11900kB min:2832kB low:3540kB high:4248kB active_anon:4632kB inactive_anon:100kB active_file:197452kB inactive_file:237316kB unevictable:0kB writepending:4kB present:519680kB managed:504736kB mlocked:0kB slab_reclaimable:5784kB slab_unreclaimable:6164kB kernel_stack:592kB pagetables:212kB bounce:0kB free_pcp:692kB local_pcp:692kB free_cma:0kB
[41312.081972] lowmem_reserve[]: 0 0 0
[41312.086149] Normal: 1445*4kB (UMH) 629*8kB (UMH) 48*16kB (UMH) 4*32kB (MH) 3*64kB (M) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 11900kB
[41312.101337] 108718 total pagecache pages
[41312.105844] 0 pages in swap cache
[41312.109615] Swap cache stats: add 0, delete 0, find 0/0
[41312.115499] Free swap  = 0kB
[41312.118813] Total swap = 0kB
[41312.122117] 129920 pages RAM
[41312.126429] 0 pages HighMem/MovableOnly
[41312.130968] 3736 pages reserved
[41312.134502] 0 pages cma reserved
[41312.138192] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[41312.148942] [  999]     0   999      306      133       4       0        0             0 adbd
[41312.158846] [ 1026]     0  1026      208      128       3       0        0             0 powerkey_daemon
[41312.169696] [ 1028]     0  1028      174      127       3       0        0             0 swupdate-progre
[41312.180456] [ 1044]     0  1044      262      199       3       0        0             0 sh
[41312.189932] [ 1066]     0  1066      330      181       4       0        0             0 dbus-daemon
[41312.201026] [ 1069]     0  1069      352      228       4       0        0         -1000 udevd
[41312.210849] [ 1109]     0  1109     2033      216       8       0        0             0 wifi_deamon
[41312.221334] [ 1129]     0  1129      575      167       4       0        0             0 wpa_supplicant
[41312.233161] [ 1159]     0  1159     5664     1681      17       0        0             0 playerdemo
[41312.243587] Out of memory: Kill process 1159 (playerdemo) score 13 or sacrifice child
[41312.253545] Killed process 1159 (playerdemo) total-vm:22656kB, anon-rss:3680kB, file-rss:3044kB, shmem-rss:0kB
Killed
root@ARM:/#

以前看到上面的信息，都会觉得害怕，因为麻烦又来了。现在也怕，不过最起码可以先看懂它是怎么回事吧，下面一个个来分析。

触发源

[41311.854276] udevd invoked oom-killer: gfp_mask=0x27080c0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK), nodemask=0, order=1, oom_score_adj=-1000

上面这行log，我们可以知道，udevd这个进程触发了oom-killer机制，触发的时候，申请4KB(page size) * 2^order大小的内存(order=1，也就是8KB)，内存也不大，相对比较正常。而申请内存时的标志是(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOTRACK)，也中规中矩，没什么异常，oom_score_adj则是在oom-killer决定杀掉那个进程时的权重，该值越大越容易被杀。继续往下看。

申请内存的标志信息如下：

__GFP_ZERO：返回已经帮忙清0的内存。

__GFP_NOTRACK：避免使用kmemcheck进行跟踪。

GFP_KERNEL：典型的内核内部分配。调用者需要ZONE_NORMAL或一个较低的区域来直接访问，但可以直接回收。

GFP_KERNEL_ACCOUNT：与GFP_KERNEL相同，不同的是分配被记为kmemcg。

堆栈

[41311.878101] CPU: 0 PID: 1069 Comm: udevd Not tainted 4.9.191 #147
[41311.885079] Hardware name: arm
[41311.889103] [<c010d3cc>] (unwind_backtrace) from [<c010a51c>] (show_stack+0x10/0x14)
[41311.897984] [<c010a51c>] (show_stack) from [<c01b2be8>] (dump_header.constprop.4+0x7c/0x1c8)
[41311.907480] [<c01b2be8>] (dump_header.constprop.4) from [<c0176404>] (oom_kill_process+0xf0/0x4d0)
[41311.917732] [<c0176404>] (oom_kill_process) from [<c0176cac>] (out_of_memory+0x348/0x3f0)
[41311.927687] [<c0176cac>] (out_of_memory) from [<c017ae5c>] (__alloc_pages_nodemask+0x884/0x928)
[41311.937826] [<c017ae5c>] (__alloc_pages_nodemask) from [<c0116428>] (copy_process.part.3+0x160/0x1574)
[41311.948461] [<c0116428>] (copy_process.part.3) from [<c011798c>] (_do_fork+0xb0/0x358)
[41311.957436] [<c011798c>] (_do_fork) from [<c0117ca4>] (sys_fork+0x20/0x28)
[41311.966475] [<c0117ca4>] (sys_fork) from [<c0106bc0>] (ret_fast_syscall+0x0/0x54)

上面的信息则是代表发生OOM时，CPU的堆栈信息，从上面大概知道申请内存时触发OOM了，打印出来的堆栈位置也很常规，内核的函数，不是设备驱动，应该问题不大，继续往下。

相信内核不相信驱动：看堆栈信息时，确认最后堆栈的位置，确认是内核的常规函数还是某些驱动的函数，如果是驱动的，需要看看该驱动是否刚好有问题。

内存信息

看完堆栈之后就到触发OOM时的系统内存信息了，这个很关键。

[41311.977605] active_anon:1158 inactive_anon:25 isolated_anon:0
[41311.977605]  active_file:49363 inactive_file:59329 isolated_file:0
[41311.977605]  unevictable:0 dirty:1 writeback:0 unstable:0
[41311.977605]  slab_reclaimable:1446 slab_unreclaimable:1541
[41311.977605]  mapped:988 shmem:26 pagetables:53 bounce:0
[41311.977605]  free:2975 free_pcp:174 free_cma:0

anon，属于进程的数据，如 Stacks、Heaps 等。

active_anon：活动内存，1158 pages，也就是4632kB；

inactive_anon：非活动内存，25 pages，也就是100kB；

isolated_anon：从anon lru临时隔离页面

缓存存储器存储当前保存在内存中的磁盘数据。

active_file：活动内存，49363 pages，也就是197452kB；

inactive_file：非活动内存，59329 pages，也就是237316kB；

isolated_file：

slab_reclaimable：系统可回收内存，1446 pages，5784kB；

slab_unreclaimable：系统不可回收内存，1541 pages，6164kB；

mapped：映射的文件页，988 pages，3952kB；（比如share memory、动态库、mmap 等都统计在内）

shmem：share memory与tmpfs等内存，同free命令的shared，26 pages，104kB；

pagetables：页表内存，用于将虚拟地址翻译为物理地址，53 pages，212kB；

bounce：

free：空闲内存，2975 pages，11900kB；

free_pcp：CPU所占用的高速缓存内存，174 pages，696kB；

free_cma：空闲cma内存大小；

文件页：内存回收也就是系统释放掉可以回收的内存，比如缓存和缓冲区就属于可回收内存。在内存管理中，通常叫文件页，大部分文件页都可以直接回收，后续有需要再重磁盘重新读取即可（如属于进程的代码段等）。

脏页：被应用程序修改过，并暂时还没有写入磁盘的数据，得先写入磁盘才可以进行内存释放。

文件映射页：除了缓存和缓冲区，通过内存映射获取的文件映射页，也是一种常见的文件页。它也可以被释放掉，下次再访问的时候，从文件重新读取。

匿名页：应用程序动态分配的堆内存称为匿名页(Anonymous Page)。

[41312.014748] Node 0 active_anon:4632kB inactive_anon:100kB active_file:197452kB inactive_file:237316kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:3952kB dirty:4kB writeback:0kB shmem:104kB writeback_tmp:0kB unstable:0kB pages_scanned:0 all_unreclaimable? no
[41312.044605] Normal free:11900kB min:2832kB low:3540kB high:4248kB active_anon:4632kB inactive_anon:100kB active_file:197452kB inactive_file:237316kB unevictable:0kB writepending:4kB present:519680kB managed:504736kB mlocked:0kB slab_reclaimable:5784kB slab_unreclaimable:6164kB kernel_stack:592kB pagetables:212kB bounce:0kB free_pcp:692kB local_pcp:692kB free_cma:0kB
[41312.081972] lowmem_reserve[]: 0 0 0
[41312.086149] Normal: 1445*4kB (UMH) 629*8kB (UMH) 48*16kB (UMH) 4*32kB (MH) 3*64kB (M) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 11900kB
[41312.101337] 108718 total pagecache pages
[41312.105844] 0 pages in swap cache
[41312.109615] Swap cache stats: add 0, delete 0, find 0/0
[41312.115499] Free swap  = 0kB
[41312.118813] Total swap = 0kB
[41312.122117] 129920 pages RAM
[41312.126429] 0 pages HighMem/MovableOnly
[41312.130968] 3736 pages reserved
[41312.134502] 0 pages cma reserved

上面的信息前面介绍的类似，可以更清晰的看到发生OOM时，各类内存信息。从上面可以清晰的看到，OOM时，active_file + inactive_file 共424MB，而系统的总内存是 129920 pages RAM 共512MB，显然，这个 active_file + inactive_file 是导致系统OOM的原因。

其他

[41312.138192] [ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[41312.148942] [  999]     0   999      306      133       4       0        0             0 adbd
[41312.158846] [ 1026]     0  1026      208      128       3       0        0             0 powerkey_daemon
[41312.169696] [ 1028]     0  1028      174      127       3       0        0             0 swupdate-progre
[41312.180456] [ 1044]     0  1044      262      199       3       0        0             0 sh
[41312.189932] [ 1066]     0  1066      330      181       4       0        0             0 dbus-daemon
[41312.201026] [ 1069]     0  1069      352      228       4       0        0         -1000 udevd
[41312.210849] [ 1109]     0  1109     2033      216       8       0        0             0 wifi_deamon
[41312.221334] [ 1129]     0  1129      575      167       4       0        0             0 wpa_supplicant
[41312.233161] [ 1159]     0  1159     5664     1681      17       0        0             0 playerdemo
[41312.243587] Out of memory: Kill process 1159 (playerdemo) score 13 or sacrifice child
[41312.253545] Killed process 1159 (playerdemo) total-vm:22656kB, anon-rss:3680kB, file-rss:3044kB, shmem-rss:0kB
Killed
root@ARM:/#

上面的信息则是系统计算应该kill哪个进程时的信息，最终 score 高的被kill，同时会限制被kill进程的内存信息，从上面的信息看，playerdemo占用的内存正常。

分析

出现OOM，可按下面的步骤进行分析：

  1. 先看触发OOM时申请内存的信息。
    例如上面的通过 __alloc_pages_nodemask申请的，gfp_mask 标志都是比较普通常见的。
    同时申请的大小是 order=1，也就8KB的大小，也不是大块内存，正常。
  2. 看现场的内存信息分布。
    通过看OOM时，内存是如何分布的。
    如果是 slab_unreclaimable 异常，不可回收内存比较大，可按照 slab 内存泄漏进行排查。
    如果是应用 rss 异常则按照应用内存泄漏。
    其他可考虑内存碎片化。

slab内存泄漏

如果在老化测试中发现系统的 slab_unreclaimable 持续增长，一般可理解为系统存在内存泄漏。此时可以按照下面的操作进行。

内核配置 CONFIG_SLUB_DEBUG 和 CONFIG_SLUB_DEBUG_ON 这两个配置，然后内核还需要增加下面的补丁：

diff --git a/mm/slub.c b/mm/slub.c
index 1600670e89ca..6f494b995092 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -4524,6 +4524,7 @@ static int list_locations(struct kmem_cache *s, char *buf,
        unsigned long *map = kmalloc(BITS_TO_LONGS(oo_objects(s->max)) *
                                     sizeof(unsigned long), GFP_KERNEL);
        struct kmem_cache_node *n;
+       bool print_buf = false;

        if (!map || !alloc_loc_track(&t, PAGE_SIZE / sizeof(struct location),
                                     GFP_TEMPORARY)) {
@@ -4551,8 +4552,16 @@ static int list_locations(struct kmem_cache *s, char *buf,
        for (i = 0; i < t.count; i++) {
                struct location *l = &t.loc[i];

-               if (len > PAGE_SIZE - KSYM_SYMBOL_LEN - 100)
-                       break;
+               if (len > PAGE_SIZE - KSYM_SYMBOL_LEN - 100) {
+                       print_buf = true;
+                       pr_err("%s\n", buf);
+                       len = 0;
+               }
+
+               /* ignore minority data */
+               if (l->count < 100)
+                       continue;
+
                len += sprintf(buf + len, "%7ld ", l->count);

                if (l->addr)
@@ -4591,6 +4600,12 @@ static int list_locations(struct kmem_cache *s, char *buf,

                len += sprintf(buf + len, "\n");
        }
+       if (print_buf) {
+               pr_info("%s\n", buf);
+               len = sprintf(buf, "sysfs node buffer size is PAGE_SIZE.");
+               len += sprintf(buf + len, "The message is more than 1 page.\n");
+               len += sprintf(buf + len, "Please get the message by kmsg\n");
+       }

        free_loc_track(&t);
        kfree(map);

上面的补丁避免在查看内存节点信息时打印不完整的问题，同时也忽略申请较少的内存对象。

在增加上面的补丁之后，将可以开始测试。在测试之前，执行 cat /proc/slabinfo 记录测试前的slabinfo，接着开始老化测试，测试到足够的时间之后，再次执行 cat /proc/slabinfo，然后对比前后两次的slabinfo，留意不同 slab object 的 num_objs 数值，如果前后明显存在差异的，则是该对象的使用存在内存泄漏（足够的测试时间是指已经明显看到系统内存有泄漏了的时间）。

假设说通过上面的操作，我们发现是 kmalloc-128 这个对象的申请释放存在泄漏，则可执行 cat /sys/kernel/slab/kmalloc-128/alloc_calls，确认都有哪些函数申请了 kmalloc-128，数值明显差异大的为怀疑对象（也可以对比测试前的情况）。

有了前面的基础，基本了解到了哪个内核函数的频繁调用导致了内存泄漏，但是该函数是被谁调用的还是不够清晰。此时可以在被调用的内存函数中增加调用 dump_stack()，使在调用该函数时打印堆栈，从而知道被谁调用(dump_stack()函数的调用可以增加判断条件，比如进入该函数多少次之后才会打印堆栈，避免过大的打印堆栈从而影响系统正常运行)。

来到这里的时候，已经是知道哪个驱动的函数调用导致内存泄漏，再跟进实际的情况修复即可。

应用内存泄漏

当出现了OOM，先确认现场是不是应用被kill时占用很大的内存(看rss)，如果是，则属于应用内存泄漏，可通过 valgrind 工具进行排查。

valgrind 工具使用时，编译之后的可执行程序不能 strip，编译增加参数 -g，同时可以使用 valgrind --leak-check=full --show-reachable=yes TEST_CMD 进行分析，留意 /proc/PID/fd/ 下是否一直增长以及申请内存使用完之后是否有及时释放。

内核内存泄漏

内核内存泄漏可通过 kmemleak 工具进行检查。可查看 内核检查内存泄漏的工具 — kmemleak。

其他 OOM 情况

出现 OOM 时，系统的 slab_unreclaimable 正常，而程序占用的 rss 也正常，那么可以考虑内存碎片导致系统申请内存时无法分配内存。可以关注系统的 /proc/pagetypeinfo 节点信息，系统内存碎片化严重的时候空闲内存全部集中在order=0(也就是最大的空闲连续内存块是一页)的情况。

这种情况下，确认是否没有开启内核的 CONFIG_COMPACTION 配置，该配置实际上是使用内核的compaction功能。类似于磁盘碎片整理：把碎的页移动整合到连续的一段空间，就留出一段连续的内存了，要注意它只能整理可移动的页面。

本文的例子log就是由于内核没有使能 CONFIG_COMPACTION 导致的内存碎片化严重，触发OOM。

有意思的文章

Linux中匿名页的访问分析

# linux # 运维 # 服务器
Logo
华为云开发者联盟

为开发者提供学习成长、分享交流、生态实践、资源工具等服务，帮助开发者快速成长。

更多推荐

cover

解锁HDC 2024之旅：从购票到报名，全程攻略

avatar 华为云开发者联盟
cover

从原始边列表到邻接矩阵Python实现图数据处理的完整指南

avatar 华为云开发者联盟
cover

华为云云原生FinOps解决方案，释放云原生最大价值

avatar 华为云开发者联盟