内存碎片问题分析

说明

• 之前在某公司，承担某款 64M小内存IPC产品开发时，出现现象：

1. 设备启动后不一会就自动重启，操作设备进行录像的话重启更快。
2. CPU占用快速飙升，飙升进程是系统进程 kworker。
3. 重启原因是内核提示oom，应用程序被kill掉后，看门狗重启的设备，崩溃时free看起来还有4~5M内存，足够内存分配（设备上申请内存较小），内核打印信息类似如下，只是数据不同。

SysRq : Show Memory
Mem-info:
Normal per-cpu:
CPU    0: hi:   18, btch:   3 usd:   3
active_anon:782 inactive_anon:503 isolated_anon:0
 active_file:307 inactive_file:705 isolated_file:0
 unevictable:0 dirty:0 writeback:0 unstable:0
 free:5480 slab_reclaimable:170 slab_unreclaimable:1367
 mapped:300 shmem:534 pagetables:69 bounce:0
Normal free:21920kB min:1024kB low:1280kB high:1536kB active_anon:3128kB inactive_anon:2012kB active_file:1228kB inactive_file:2820kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:65024kB mlocked:0kB dirty:0kB writeback:0kB mapped:1200kB shmem:2136kB slab_reclaimable:680kB slab_unreclaimable:5468kB kernel_stack:792kB pagetables:276kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 104*4kB 70*8kB 55*16kB 25*32kB 27*64kB 25*128kB 34*256kB 9*512kB 1*1024kB 0*2048kB 0*4096kB 0*8192kB = 21920kB
1546 total pagecache pages
16384 pages of RAM
5654 free pages
5002 reserved pages
1537 slab pages
2063 pages shared
0 pages swap cached

问题分析

• free显示内存充足，但是出现oom，通过崩溃时内核如下打印，4kB等小块内存有很多块，但是大块内存无，内存碎片较多，内存被分为了很多小块，申请大块内存就直接oom。

Normal: 104*4kB 70*8kB 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB = xxxkB

• 测试发现现象：录像会加快设备重启，但是和具体功能无关，不录像也会，根据内存情况猜测可能是内存问题，因此通过一些会申请大量内存的功能测试可得：系统进程cpu占用飙升是内存分配导致的，最终定位于内核中开启了内存碎片整理，内存碎片较多，导致内核进程在不断合并内存碎片。

内存碎片信息查看

• 应用层内存是通过内存伙伴系统进行管理，可以通过命令查看各种大小的内存块数量进行分析。

1. 通过sysrq-trigger接口

echo "m" > /proc/sysrq-trigger
dmesg

• 在dmesg信息中可以看到类似于内核oom时的打印。

2. 通过buddyinfo接口

cat /proc/buddyinfo 
Node 0, zone   Normal     92     66     54     25     27     25     34      9      1      0      0      0 

• 两种方法的显示结果是一致的，都是显示4kb，8kb， 16kb…大小内存块的数量； 可以看出：只有normal分区，一共还剩 21M 左右， 4kB的有104块，8kB的有70块。