linux出现oom分析流程

背景

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] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[41311.897984] [] (show_stack) from [] (dump_header.constprop.4+0x7c/0x1c8)
[41311.907480] [] (dump_header.constprop.4) from [] (oom_kill_process+0xf0/0x4d0)
[41311.917732] [] (oom_kill_process) from [] (out_of_memory+0x348/0x3f0)
[41311.927687] [] (out_of_memory) from [] (__alloc_pages_nodemask+0x884/0x928)
[41311.937826] [] (__alloc_pages_nodemask) from [] (copy_process.part.3+0x160/0x1574)
[41311.948461] [] (copy_process.part.3) from [] (_do_fork+0xb0/0x358)
[41311.957436] [] (_do_fork) from [] (sys_fork+0x20/0x28)
[41311.966475] [] (sys_fork) from [] (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] [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[41311.897984] [] (show_stack) from [] (dump_header.constprop.4+0x7c/0x1c8)
[41311.907480] [] (dump_header.constprop.4) from [] (oom_kill_process+0xf0/0x4d0)
[41311.917732] [] (oom_kill_process) from [] (out_of_memory+0x348/0x3f0)
[41311.927687] [] (out_of_memory) from [] (__alloc_pages_nodemask+0x884/0x928)
[41311.937826] [] (__alloc_pages_nodemask) from [] (copy_process.part.3+0x160/0x1574)
[41311.948461] [] (copy_process.part.3) from [] (_do_fork+0xb0/0x358)
[41311.957436] [] (_do_fork) from [] (sys_fork+0x20/0x28)
[41311.966475] [] (sys_fork) from [] (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,linux,运维,服务器,OOM)