在实际业务场景中，我们经常会遇到这种情况：基于虚拟机（vm）环境部署的spring boot应用服务，在运行过程中常常会将内存利用率推到极限，甚至达到90%以上。此时，许多同事会呼吁领导进行内存扩容。然而，这样的需求是否合理？作为技术人员，我们应该如何应对和解决这个问题？本文将从linux内存结构、内存分析以及oom killer三个方面结合笔者多年的实践经验进行探讨，若有不足之处，欢迎大家批评指正。
内存结构
从宏观角度来看，内存管理系统是操作系统的核心部分之一。在内存管理的系统调用方面，虽然POSIX并未指定任何具体的系统调用，但Linux却拥有自己的内存管理系统调用，主要包括以下几种：
- brk 通过指定数据段之外的第一个字节地址来调整数据段的大小。如果新值大于原值，数据区将扩展，反之则缩小。
- mmap和unmap 系统调用用于控制文件映射。mmap的第一个参数addr决定文件映射的地址，必须是页面大小的倍数。若为0，系统会分配并返回地址a。第二个参数len表示需要映射的字节数，同样是页面大小的倍数。prot参数决定映射文件的保护位，可以设置为可读、可写、可执行或它们的组合。flags参数控制文件的私有性或可读性以及addr的必要性。fd是需要映射的文件描述符，仅打开的文件可以被映射。offset参数指示文件映射的起始位置，不一定从零开始。
Linux的内存管理涉及广泛且复杂的领域，从早期计算机开始，我们实际使用的内存往往比系统中存在的物理内存多。为此，内存分配策略引入了虚拟内存（Virtual Memory），通过在多个进程之间共享虚拟内存，使系统能够有效管理和分配资源。以下是Linux系统的总览图：
（此图源自网络）
Linux内存通常被认为是“物理内存”，但只有内核可以直接访问物理内存。进程需要访问内存时，Linux内核为每个进程提供独立的虚拟地址空间，访问的是虚拟内存。虚拟内存空间内部划分为内核空间和用户空间：
- 进程在用户态只能访问用户空间内存。
- 进程进入内核态才能访问内核空间内存。
- 每个进程都包含内核空间，但这些内核空间都关联相同的物理内存。
内存映射将虚拟内存地址映射到物理内存地址。内核为每个进程维护一张页表，记录虚拟地址和物理地址的映射关系，页表存储在CPU的内存管理单元（MMU）中，处理器通过硬件直接查找要访问的内存。以下是内核线形地址空间布局图：
简要描述如下：
- 内核直接映射空间PAGE_OFFSET~VMALLOC_START，kmalloc和__get_free_page()分配的是这里的页面，通过Slab分配器直接分配物理页并转换为逻辑地址，适用于分配小段内存。此区域包含内核镜像、物理页框表mem_map等资源。
- 内核动态映射空间VMALLOC_START~VMALLOC_END，被vmalloc使用，可表示的空间较大。
- 内核永久映射空间PKMAP_BASE ~ FIXADDR_START，使用kmap。
- 内核临时映射空间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
简要解析如下：
- VIRT：虚拟内存，包括进程的代码段、数据段、共享内存、已申请的堆内存和已换出的内存等，已申请但未分配物理内存的内存也计入虚拟内存。
- RSS：常驻内存，是进程实际使用的物理内存，不包括Swap和共享内存。
- SHR：共享内存，包括与其他进程共同使用的真实共享内存、加载的动态链接库以及程序的代码段。
- %MEM：进程使用物理内存占系统内存的百分比。
[administrator@JavaLangOutOfMemory ~ ] %free
total used free shared buff/cache available
Mem: 2031744 98176 1826192 8784 107376 1800144
Swap: 2097148 0 2097148此命令输出内容简单，主要打印已用、剩余、可用、共享内存以及缓存等信息。部分参数释义如下：
- Shared：共享内存，通过Tmpfs实现，其大小即Tmpfs使用的内存大小。
- Available：可用内存，是新进程可以使用的最大内存，包括剩余内存和未使用的内存。
- 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
简要解析如下：
- si：换入，每秒从磁盘读入虚拟内存的大小，若此值长时间持续大于0，表示物理内存不足或内存泄漏，需要定位问题。
- 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()，执行流程如下：
- 调用check_panic_on_oom()检查是否允许执行内核恐慌，若允许则需要重启系统。
- 若定义了/proc/sys/vm/oom_kill_allocating_task，即允许终止当前正在申请分配物理内存的进程，则杀死当前进程。
- 调用select_bad_process，选择badness score最高的进程。
- 调用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系统内存解析的内容到此结束，大家如有疑问、想法及建议，欢迎留言沟通。
