Linux系统之 OOM 解析

在实际业务场景中，我们经常会遇到这种情况：基于虚拟机（vm）环境部署的spring boot应用服务，在运行过程中常常会将内存利用率推到极限，甚至达到90%以上。此时，许多同事会呼吁领导进行内存扩容。然而，这样的需求是否合理？作为技术人员，我们应该如何应对和解决这个问题？本文将从linux内存结构、内存分析以及oom killer三个方面结合笔者多年的实践经验进行探讨，若有不足之处，欢迎大家批评指正。

内存结构

从宏观角度来看，内存管理系统是操作系统的核心部分之一。在内存管理的系统调用方面，虽然POSIX并未指定任何具体的系统调用，但Linux却拥有自己的内存管理系统调用，主要包括以下几种：

1. brk 通过指定数据段之外的第一个字节地址来调整数据段的大小。如果新值大于原值，数据区将扩展，反之则缩小。
2. mmap和unmap 系统调用用于控制文件映射。mmap的第一个参数addr决定文件映射的地址，必须是页面大小的倍数。若为0，系统会分配并返回地址a。第二个参数len表示需要映射的字节数，同样是页面大小的倍数。prot参数决定映射文件的保护位，可以设置为可读、可写、可执行或它们的组合。flags参数控制文件的私有性或可读性以及addr的必要性。fd是需要映射的文件描述符，仅打开的文件可以被映射。offset参数指示文件映射的起始位置，不一定从零开始。

Linux的内存管理涉及广泛且复杂的领域，从早期计算机开始，我们实际使用的内存往往比系统中存在的物理内存多。为此，内存分配策略引入了虚拟内存（Virtual Memory），通过在多个进程之间共享虚拟内存，使系统能够有效管理和分配资源。以下是Linux系统的总览图：

（此图源自网络）

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和Vmstat命令来追踪和观察内存的动态变化，以实时了解操作系统的资源状态。以下是相关命令的示例输出及其解析：

[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. VIRT：虚拟内存，包括进程的代码段、数据段、共享内存、已申请的堆内存和已换出的内存等，已申请但未分配物理内存的内存也计入虚拟内存。
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微服务，在业务促销、压力测试或网络抖动等特殊时刻，服务可能会突然无预警地被终止。此时，我们需要快速定位问题原因。

这种情况通常是由于内存溢出（OOM，Out Of Memory）导致的。Linux通过OOM Killer机制进行自我保护，防止内存不足时出现严重问题。Linux内核会监控占用内存过大的进程，特别是在某一时刻内存使用快速增长的进程，以防止系统内存耗尽而自动终止这些进程。系统内核检测到内存不足时，会通过内核源代码linux/mm/oom_kill.c中的out_of_memory()函数触发，然后调用select_bad_process()选择并终止一个“bad”进程。选择“bad”进程的标准是通过oom_badness()函数计算的，算法简单且直接：最“bad”的进程就是最占用内存的进程。

OOM Killer源码解析

OOM Killer的核心函数是out_of_memory()，执行流程如下：

1. 调用check_panic_on_oom()检查是否允许执行内核恐慌，若允许则需要重启系统。
2. 若定义了/proc/sys/vm/oom_kill_allocating_task，即允许终止当前正在申请分配物理内存的进程，则杀死当前进程。
3. 调用select_bad_process，选择badness score最高的进程。
4. 调用oom_kill_process，终止选择的进程。

通过分析Badness Score的计算函数，我们可以理解OOM Killer如何选择需要终止的进程。具体源码如下：

unsigned long oom_badness(struct task_struct *p, struct mem_cgroup *memcg,
                          const nodemask_t *nodemask, unsigned long totalpages){
        long points;
        long adj;
        /* 若该进程不能被终止，则分数返回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或进程被标记为不可终止，或进程处于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（常驻物理内存）来选择进程进行终止操作，从而释放相关内存以进行系统自我保护。有关OOM Killer的配置、查看及分析将在后续文章中详细介绍，请大家留意。

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

以上就是Linux系统之 OOM 解析的详细内容，更多请关注php中文网其它相关文章！