【内存优化】内存优化以及oom排查整体思路

linux疑难问题排查实战专栏，分享了作为公司专家，在解决内存、性能、各类死机等疑难问题的排查经验，认真学习可以让你在日后工作中大放光彩。

        本文总结介绍了项目开发过程中oom排查和内存优化的一些方法，主要是从内存问题查看到堆内存、栈内存、数据段内存优化为导向，结合实际优化实例介绍工具和方法的运用，展示每种优化方法优化过程，希望对读者有所帮助。

从下面几个角度展开：

        1. 分析oom打印，确认各个进程物理内存占用情况，是否有明显使用不合理的进程

        2. 确认glibc中的malloc缓存机制

        3. Free、/proc/meminfo确认内存是否在逐步减少

        4. 内存泄漏问题定位

        5. 内存优化：栈、数据段、代码段优化

        6. 其他优化点：drop_cache、线程裁剪、程序瘦身、结构体裁剪等

1、oom__killer概念介绍

        oom__killer（out of memory killer）是Linux内核的一种内存管理机制，在系统可用内存较少的情况下，内核为保证系统还能够继续运行下去，会选择杀掉一些进程释放掉一些内存。

        通常oom_killer的触发流程是：进程A想要分配物理内存（通常是当进程真正去读写一块内核已经“分配”给它的内存）->触发缺页异常->内核去分配物理内存->物理内存不够了，触发OOM。

        一句话说明oom_killer的功能：当系统物理内存不足时，oom_killer遍历当前所有进程，根据进程的内存使用情况进行打分，然后从中选择一个分数最高的进程，杀之取内存。另外可能是内核驱动、内存碎片化严重等问题也会触发OOM。

2、oom问题分析

2.1oom日志分析

1、谁触发OOM

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

        先来看一下第一行，它给出了oom killer是由谁触发的信息，order=0告诉我们所请求的内存的大小是多少，即ai0_P0_MAIN请求了2的0次方这么多个page的内存，也就是一个page(4KB)。

2、oom时内存情况

        可以看到normal区free的内存只有4084KB，比系统允许的最小值(min)还要低，这意味着application已经无法再从系统中申请到内存了，并且系统会开始启动oom killer来缓解系统内存压力。

        这里我们说一下一个常见的误区，就是有人会认为触发了oom-killer的进程就是问题的罪魁祸首，比如我们这个例子中的这个ai0_P0_MAIN进程。其实日志中invoke oom-killer的这个进程有时候可能只是一个受害者，因为其他应用／进程已将系统内存用尽，而这个invoke oomkiller的进程恰好在此时发起了一个分配内存的请求而已。在系统内存已经不足的情况下，任何一个内存请求都可能触发oom killer的启动。

        oom-killer的启动会使系统从用户空间转换到内核空间。内核会在短时间内进行大量的工作，比如计算每个进程的oom分值，从而筛选出最适合杀掉的进程。我们从日志中也可以看到最终杀死的进程。

3、进程内存占用分析

        Rss是物理内存的占用，可以看到build和busybox占用较多，build是主程序，占用合理，busybox占用250M明显不合理（单位是4KB）。

        此oom打印为真实开发案例：由于测试工程师运行测试脚本压力测试，测试脚本大量占用内存导致oom，非问题。

2.2Glibc缓存确认

2.2.1内存站岗问题原因

        Glibc使用了ptmalloc的内存管理方式。Glibc申请内存时是从分配区申请的，分为主分配区和非主分配区，分配区都有锁，在分配内存前需要先获取锁，然后再去申请内存。

        一般进程都是多线程的，当多个线程同时需要申请内存时，如果只有一个分配区，那么效率太低。glibc为了支持多线程的内存申请释放，会在多个线程同时需要申请内存时根据cpu核数分配一定数量的分配区，将分配区分配给线程。

        内存申请基本原理：当用户调用malloc申请内存时，glibc会查看是否已经缓存了内存，如果有缓存则会优先使用缓存内存，返回一块符合用户请求大小的内存块。

        如果没有缓存或者缓存不足则会去向操作系统申请内存（可通过brk、mmap申请内存），然后切一块内存给用户，如图所示。

        内存释放基本原理：当业务模块使用完毕后调用free释放内存时，glibc会检查该内存块虚拟地址上下内存块的使用状态（fast bin除外）。若其上一块内存空闲，则与上一块内存进行合并。若下一块内存空闲，则与下一块内存进行合并。

        若下一块内存时top chunk（top chunk一直是空闲的），则看top chunk的大小是否超过一个阈值，如果超过一个阈值则将其释放给OS，如图所示。

        内存站岗概念：内存站岗指的是glibc从OS申请到内存后分配给业务模块，业务模块使用完毕后释放了内存，但是glibc没有将这些空闲内存释放给OS，也就是缓存了很多空闲内存无法归还给系统的现象。

        内存站岗原因：glibc设计时就确定其内存是用于短生命周期的，因此在设计上内存释放给OS的时机是当top chunk的大小超过一个阈值时会释放top chunk的一部分内存给OS。当top chunk不超过阈值就不会释放内存给OS。

        那么问题来了，若与top chunk相邻的内存块一直在使用中，那么top chunk就永远也不会超过阈值，即便业务模块释放了大量内存，达到几十个G 或者上百个G，glibc也是无法将内存还给OS的。

2.2.2问题确认

        在主程序中隔一段时间调用一次malloc_stats、mallinfo，都是glibc提供的函数，用户打印内存分配函数（如malloc、free）的详细调试信息。

代码实现：

static void print_mallinfo()
{
    malloc_stats();

    struct mallinfo mi = mallinfo();

    printf("\t arena=%d, ordblks=%d, smblks=%d, hblks=%d, hblkhd=%d  \n\t usmblks=%d, fsmblks=%d, "
          "uordblks=%d, fordblks=%d, keepcost=%d\n\n",
        mi.arena,    /* non-mmapped space allocated from system */
         mi.ordblks,  /* number of free chunks */
         mi.smblks,   /* number of fastbin blocks */
         mi.hblks,    /* number of mmapped regions */
         mi.hblkhd,   /* space in mmapped regions */
         mi.usmblks,  /* maximum total allocated space */
         mi.fsmblks,  /* space available in freed fastbin blocks */
         mi.uordblks, /* total allocated space */
         mi.fordblks, /* total free space */
         mi.keepcost  /* top-most, releasable (via malloc_trim) space */
     );
 }

打印内容：

如果系统申请的内存（system bytes）远远大于在使用的内存（in use bytes），那么就怀疑可能是内存站岗问题导致glibc缓存过多。

2.2.3解决办法

1、减少子分配区个数

mallopt(M_ARENA_MAX, 2);

2、降低mmap阈值：默认值是128KB

减少内存碎片，大于64KB就直接使用mmap的方式申请内存。

mallopt(M_MMAP_THRESHOLD, 64*1024);

3、释放空闲区以减少内存碎片

malloc_trim()

        当我们通过free()释放区块时,如果相邻的空闲区块可以合并,glibc会将它们合并。但是,如果相邻的空闲区块来自不同的bin,glibc则无法将它们合并，这就会产生内存碎片。malloc_trim()的作用就是尝试释放这些未能合并但空闲的小区块,尽量减少内存碎片

        malloc_trim可以在可用内存小图某个阈值之后隔一段时间调用一次。

2.3内存泄漏

2.3.1确认是否发生泄漏

        内存泄漏排查的前提一定是确认存在泄漏的，经过2.2章节首先排除Glibc缓存的影响，那怎样就认为是发生了内存泄漏呢？

        随着程序运行，占用内存大小持续增长，及时程序闲置也是如此，那我们认为是存在内存泄漏的。

        Meminfo查看，free和MemAvailable都在逐步减少，直至oom死机，那么就是存在内存泄漏问题的。

 # cat /proc/meminfo 
MemTotal:         365924 kB   //总内存大小
MemFree:           74584 kB   //剩余内存
MemAvailable:     251220 kB   //可用内存：包含了部分buffer和cache
Buffers:           58952 kB   //设备操作缓存，如访问/dev/sda1
Cached:           164596 kB   //文件操作缓存，如访问某个文件

2.3.2泄漏源定位

        内存泄漏定位还是蛮多的：ASAN、valgrind、gperfTools、malloc重载等，在之前文章中我们已经介绍过了，读者可根据自己的需求进行选择。

详见：内存泄漏问题排查

3、内存优化

        在经过第二章的学习，我们已经可以排除Glibc缓存和内存泄漏问题导致的内存不足死机了，本章我们开始学习如何进行内存优化，发现我们程序中的不合理使用。

3.1栈内存优化

        在之前文章我们已经讲解过了，详见：栈上局部变量定义过大导致设备oom

大概思路：

        1、ulimit –a确认栈内存大小；如：4096KB

        2、通过cat proc/PID/smaps命令查看此进程中内存的申请信息，并搜索所有的4096KB为栈内存

        3、依次查看每个栈对应的真实物理内存Rss，可能绝大多数都是30KB以下，超过100KB的我们就需要关注一下是否代码实现时定义了超大的局部变量

        4、反汇编搜索“sp, sp, #”字段，后面跟随着是栈的大小

        5、可以使用脚本处理，按照大小排序，从上至下按照栈大小结合代码逐一排查

3.2堆内存优化

        堆内存的优化首先得确认何处申请了堆内存，堆内存申请的小，才能确认此处的堆内存申请是否合理，一般方法：

        1. 使用gerftools，打印出所有内存申请的堆栈，按照从打到小排序，确认内存申请是否合理。（不推荐）

        2. 各个模块实现自己的调试信息，在malloc前进行封装，每次的申请和释放内存管理起来，可用调试命令查看各模块申请未释放的内存大小、名字，各模块独自结合代码分析占用是否合理。（推荐）

        3. Malloc重载，所有申请未释放的内存打堆栈，依次解析出符号分析。（不推荐）

3.3数据段

        在之前文章我们已经讲解过了，详见：《【内存】数据段大小分析.docx》

        数据段的分析主要包含：.bss、.rodata、.data段

大体思路：

        1. 使用nm打印出不各个数据段中发符号的地址、大小、变量名称：arm-linux-nm --format=sysv build | grep .bss > bss.txt

        2. 使用脚本提取变量名称和大小

        3. 按照大小排序，从大到小依次优化每个变量

3.4代码段

        在之前文章我们已经讲解过了，详见：《【内存】代码段大小分析.docx》

大体思路：

1. 生成可执行程序build的反汇编文件

arm-mix410-linux-objdump -d build > objdump.log

2. nm解析执行程序依赖的各个库，并针对每个库生成一个符号文件

arm-mix410-linux-nm -A lib*.a | grep T > ./*.a.log

3. 依次遍历每个*.a.log文件，解析出函数名，在objdump.log文件中搜索，确认开始地址和结束地址以及函数代码段大小，生成*.a.log.ok文件

4. 依次遍历每个*.a.log.ko文件，计算每个库的代码段大小

3.5其他优化项

3.5.1drop_cache

定期释放linux的page cache和reclaimable slab cache，加快内存回收：

#清理文件页、目录项、inodes等各种缓存
$echo 3 > /proc/sys/vm/drop_caches

3.5.2线程裁剪

在实际的大型项目中，由于代码的不断演进，维护人员的不断变化，会存在很多无效的线程，如：

1. A项目使用的线程，B项目无需创建，但是由于代码没有做相应的控制，即使B项目部需要，但是仍然创建了

2. 某个业务功能，根据用户个数或者通道个数来创建线程，每新增一路则新增一个线程，但实际上多个对象共用一个线程也是能处理过来的。

增对上述情况，我们可以先查看线程个数，然后增加每个线程进行优化：

1. gdb thread apply all bt：查看所有线程，并结合代码依次确认其合理性

2. pidstat查看：查看pid对应的所有线程

./pidstat -p pid -t 

注：

1. 想在上述两种方法中看到线程名字，需要在线程执行体中调用：

prctl(PR_SET_NAME, "thread_name");  //注意是在线程执行体中调用

2. 优化出的物理内存并不是ulimit所看到的线程大小，ulimit对应的是虚拟内存，物理内存实际没这么大

3.5.3程序瘦身

针对ko驱动、动态库和可执行程序，进行strip，删除调试信息

strip -S lib_exe_name

缺点：调试时不方便，无法解析符号

3.5.4结构体裁剪

减少复杂嵌套结构体的大小：

1. 根据情况减小数组下标

2. 根据本产品业务需求，可用编译宏进行控制处理，删除较大的无效结构体成员

3.5.5内存文件系统

        Mount查看当前设备挂载情况，找到/dev/mem行，/dev/mem是将后面的目录挂载到内存，目录中文件是存储在内存中的，可以对该目录中文件大小做一个优化。

        查看/var目录，对/var目录做一个优化。

3.5.6驱动加载

        驱动加载也会申请内存，一些无用的驱动可以取消加载

4、总结

        本文总结介绍了项目开发过程中oom排查和内存优化的一些方法，主要是从内存问题查看到堆内存、栈内存、数据段内存优化为导向，结合实际优化实例介绍工具和方法的运用，展示每种优化方法优化过程，希望对读者有所帮助。