Linux系统之 OOM 解析

在实际的业务场景中，有没有发现这样一种场景：基于 VM 环境上面所部署的 Spring Boot 应用服务，往往在运行过程中将内存利用的足够“猥琐”，常常达到 90% 甚至以上，此时，很大一部分伙伴就开始“叫”了。曰：领导，内存不够了，赶紧扩容！！！（此刻，有大佬肯定在想：扩你妹，整天搞这些没用的～）

那个傻子是不是疯了？不知道作为所谓的“技术”人员，大家是如何面对的，如何解决？本文将聚焦于 Linux 内存结构、内存分析以及 OOM killer 等 3 个方面以及笔者多年的实践经验总结进行“吹牛逼”，当然，若吹的不好，欢迎大家扔砖、鸡蛋。

内存结构

从宏观角度而言，内存管理系统是操作系统最重要的部分之一 。 在内存管理的系统调用方式，事实上，基于 POSIX 并没有给内存管理指定任何的系统调用。然而，Linux 却有自己的内存系统调用，主要系统调用如下：

1、brk 通过给出超过数据段之外的第一个字节地址来指定数据段的大小。如果新的值要比原来的大，那么数据区会变得越来越大，反之会越来越小。

2、mmap 和 unmap 系统调用会控制映射文件。mmp 的第一个参数 addr 决定了文件映射的地址。它必须是页面大小的倍数。如果参数是 0，系统会分配地址并返回 a。第二个参数是长度，它告诉了需要映射多少字节。它也是页面大小的倍数。prot 决定了映射文件的保护位，保护位可以标记为 可读、可写、可执行或者这些的结合。第四个参数 flags 能够控制文件是私有的还是可读的以及 addr 是必须的还是只是进行提示。第五个参数 fd 是要映射的文件描述符。只有打开的文件是可以被映射的，因此如果想要进行文件映射，必须打开文件；最后一个参数 offset 会指示文件从什么时候开始，并不一定每次都要从零开始。

针对 Linux 内存管理及实现，其实其涉及的面较广，较为复杂，从计算机早期开始，我们在实际的业务场景中所使用的内存往往都要比系统中实际存在的内存多。为此，内存分配策略克服了这一限制，并且其中最有名的就是引入： 虚拟内存(Virtual Memory)。通过在多个竞争的进程之间共享虚拟内存，虚拟内存得以让系统有更多的内存，以方便维护系统资源的分配。先来张总概览图，具体如下所示：

（此图源自网络）

Linux 内存，通常被认为指的是“物理内存”，然而，只有内核才可以直接访问物理内存，进程需要访问内存，Linux 内核则需要为每个进程都提供一个独立的虚拟地址空间，访问的是虚拟内存。

通常而言，虚拟内存空间的内部被划分为内核空间和用户空间：

1、进程在用户态，只能访问用户空间内存

2、进程进入内核态才能访问内核空间内存

3、每个进程都包含内核空间，但这些内核空间都关联相同的物理内存

而针对内存映射， 其主要 将虚拟内存地址映射到物理内存地址，为了完成内存映射。内核每个进程都维护了一张页表，记录虚拟地址和物理地址的映射关系，页表实际存储在CPU 的内存管理单元 MMU，这样处理器就可以直接通过硬件找出要访问的内存。

再来一张内核线形地址空间布局图，具体可参考如下“硬核”示意图：

针对上述结构图，简单描述如下：

1、内核直接映射空间 PAGE_OFFSET~VMALLOC_START，kmalloc和__get_free_page()分配的是这里的页面。二者是借助 Slab分配器，直接分配物理页再转换为逻辑地址（物理地址连续）。适合分配小段内存。此区域 包含了内核镜像、物理页框表mem_map 等资源。

2、内核动态映射空间 VMALLOC_START~VMALLOC_END，被 vmalloc 用到，可表示的空间大。

3、内核永久映射空间 PKMAP_BASE ~ FIXADDR_START，kmap

4、内核临时映射空间 FIXADDR_START~FIXADDR_TOP，kmap_atomic

内存分析

针对内存分析部分，其实可利用的手段或策略较多，基于不同段位的水平高低之分，通常，我们可以 借助 Top、Free 命令以及 Vmst at 命令进行追踪及观测内存的动态活动变化趋势，以实时了解当前操作系统的资源水位，具体如下所示：

[administrator@JavaLangOutOfMemory ~ ] %top
 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 
   1 root      20   0  128032   7996   5556 S   80.0  80.4   0:01.03 java  
   2 root      20   0       0      0      0 S   0.0  0.0   0:00.00 kthreadd

基于上述输出结果，简要解析如下：

1、VIRI: 虚拟内存，包括了进程的代码段、数据段、共享内存、已经申请的堆内存和已经换出的内存等，已经申请的内存，即使还未分配物理内存，也算做虚拟内存

2、RSS: 常驻内存，是进程实际使用的物理内存，不包括 Swap 和共享内存

3、SHR: 共享内存，包括与其他进程共同使用的真实共享内存，包括加载的动态链接库以及程序的代码段

4、%MEM: 进程使用物理内存占系统内存的百分比

[administrator@JavaLangOutOfMemory ~ ] %free            
                       total        used        free      shared  buff/cache   available
Mem:        2031744       98176     1826192        8784      107376     1800144
Swap:       2097148           0     2097148

此命令行输出内容较为简单：主要打印已用、剩余、可用、共享内存以及缓存等信息。部分参数释义如下所示：

1、Shared: 共享内存, 共享内存是通过 Tmpfs 实现的，它的大小就是 Tmpfs 使用的内存大小。

2、Available: 可用内存，是新进程可以使用的最大内存，包括剩余内存和还未使用的内存。

3、Buffer/Cache: 缓存包括两部分，一部分是磁盘读取文件的页缓存，用来缓存从磁盘读取的数据，加速以后再次访问速度，另一部分是 Slab 分配的可回收缓存；缓冲区是对原始磁盘的临时存储，用来缓存将要写入磁盘的数据，统一优化磁盘写入。

[administrator@JavaLangOutOfMemory ~ ] %vmstat 1 1 
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- 
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st 
  1  0      0 1815348   2108 111872    0    0     1     0   11   11  0  0 100  0  0

基于上述输出结果，简要解析如下:

1、si: 换入，每秒从磁盘读入虚拟内存的大小，若此值 长时间 持续大于0，表示物理内存不够或者内存泄漏，需要定位问题。

2、so: 换出，每秒从内存写入磁盘的大小，若 此 值 长时间 持续 大于0，表示物理内存不够用，需要排查内存问题。

OOM Killer

通常有这样的一种场景：若一台 VM （虚拟机）上部署多个应用服务，此处，暂以 Spring Boot 微服务为例，在某种特殊的时刻，例如：业务促销、压力测试或当某一个联机负载节点或因网络抖动而挂掉时，此台 VM 上的服务突然在毫无征兆的情况下，突然被“挂掉”。

与此同时，我们开始搜集相关线索，以便能够快速定位到问题原因，将“罪魁祸首”抓捕归案。

那么，为什么会出现这种问题？它是如何产生的？ OOM，全称为 “Out Of Memory”，即 内存溢出。OOM Killer 是 Linux 自我保护的方式，防止内存不足时出现严重问题。

Linux 内核所采用的此种机制 会 时不时监控所运行中占用内存过大的进程，尤其针对在某一种瞬间场景下占用内存较快的进程，为了防止操作系统内存耗尽而不得不自动将此进程 Kill 掉。通常，系统内核检测到系统内存不足时，筛选并终止某个进程的过程可以参考内核源代码：linux/mm/oom_kill.c，当系统内存不足的时候，out_of_memory()被触发，然后调用 select_bad_process() 选择一个 ”bad” 进程杀掉。如何判断和选择一个”bad 进程呢？Linux 操作系统选择”bad”进程是通过调用 oom_badness()，挑选的算法和想法都很简单很朴实：最 bad 的那个进程就是那个最占用内存的进程。

OOM Killer 源码解析

OOM killer的核心函数是 out_of_memory(), 执行流程如下:

1、调用 check_panic_on_oom() 检查是否允许执行内核恐慌，假如允许，需要重启系统。

2、若定义了 /proc/sys/vm/oom_kill_allocating_task 即允许 Kill 掉当前正在申请分配物理内存的进程，那么杀死当前进程。

3、调用 select_bad_process，选择 badness score 最高的进程。

4、调用 oom_kill_process, 杀死选择的进程。

我们通过分析 Badness Score 的计算函数来理解 OOM Killer 是如何选择需要被 Kill 掉的进程，具体源代码可参考如下所示：

unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,                         
                                               const nodemask_t *nodemask, unsigned long totalpages)
{       
                long points;       
                long adj;  
                
                /* 假如该进程不能被kill, 则分数返回0. */   
                if (oom_unkillable_task(p, memcg, nodemask))        
                              return 0;  
                
                p = find_lock_task_mm(p);       
                if (!p)              
                              return 0;  
                              
                /* 获取该进程的 oom_score_adj, 这个是用户为进程设置的 badness score         
                 * 调整值，假如这个值为-1000或者进程被标记为不可被kill，或者进程处于        
                 * vfork()过程，badness score返回0. */     
               adj = (long)p->signal->oom_score_adj;    
               if (adj == OOM_SCORE_ADJ_MIN ||                        
                                            test_bit(MMF_OOM_SKIP, &p->mm->flags) ||                      
                                            in_vfork(p)) {           
                        task_unlock(p);             
                        return 0;       
                }  
                
                /* badness score分数 = 物理内存页数 + 交换区页数 + 页表Page Table数量. */      
                points = get_mm_rss(p->mm) + get_mm_counter(p->mm, MM_SWAPENTS) +             
                              mm_pgtables_bytes(p->mm) / PAGE_SIZE;       
                task_unlock(p);  
                
                /* 利用以下公式对 badness score 值进行调整. */      
                adj *= totalpages / 1000;   
                points += adj;  
                
                /* 返回 badness score, 假如等于0, 则返回 1. */       
                return points > 0 ? points : 1;
}

通过对 Badness Score 计算函数的分析，我们可以发现 OOM Killer 是基于 RSS 即常驻的物理内存来选择进程进行 Kill 操作， 从而释放相关内存以进行系统自我保护。有关 OOM Killer 相关配置、查看及分析将于后续文章给出，大家到时留意查看。

综上所述，本篇文章主要通过基于对 Linux 内存结构、分析及 OOM Killer 3个核心维度，从主动及被动场景等 2 方面对 Linux 操作系统内存的剖析，以探讨在实际的业务场景中，内存表现的相关活动及经验认知。 至此，关于 Linux 系统内存 解析相关内容本文到此为止，大家有什么疑问、想法及建议，欢迎留言沟通。