内存分页由于内存空间都是预先划分好的，也就不会像内存分段一样，在段与段之间会产生间隙非常小的内存，这正是分段会产生外部内存碎片的原因。而采用了分页，页与页之间是紧密排列的，所以不会有外部碎片。但是，因为内存分页机制分配内存的最小单位是一页，即使程序不足一页大小，我们最少只能分配一个页，所以页内会出现内存浪费，所以针对内存分页机制会有内部内存碎片的现象。如果内存空间不够，操作系统会把其他正在运行的进程中的「最近没被使用」的内存页面给释放掉，也就是暂时写在硬盘上，称为换出(Swap Out)。一旦需要的时候，再加载进来，称为换入(SwapIn)。所以，一次性写入磁盘的也只有少数的-个页或者几个页，不会花太多时间，内存交换的效率就相对比较高。

更进一步地，分页的方式使得我们在加载程序的时候，不再需要一次性都把程序加载到物理内存中。我们完全可以在进行虚拟内存和物理内存的页之间的映射之后，并不真的把页加载到物理内存里，而是只有在程序运行中，需要用到对应虚拟内存页里面的指令和数据时，再加载到物理内存里面去。

Q：分页机制下，虚拟地址和物理地址是如何映射的?

在分页机制下，虚拟地址分为两部分，页号和页内偏移。页号作为页表的索引，页表包含物理页每页所在物理内存的基地址，这个基地址与页内偏移的组合就形成了物理内存地址，见下图。

总结一下，对于一个内存地址转换，其实就是这样三个步骤:

把虚拟内存地址，切分成页号和偏移量;
根据页号，从页表里面，查询对应的物理页号;
直接拿物理页号，加上前面的偏移量，就得到了物理内存地址。

Q：简单的分页有什么缺陷吗?

有空间上的缺陷。

因为操作系统是可以同时运行非常多的进程的，那这不就意味着页表会非常的庞大。

在 32 位的环境下，虚拟地址空间共有 4GB，假设一个页的大小是 4KB(2^12)那么就需要大约 100 万 (2^20)个页，每个「页表项」需要 4 个字节大小来存储，那么整个 4GB 空间的映射就需要有 4MB的内存来存储页表。

这 4MB 大小的页表，看起来也不是很大。但是要知道每个进程都是有自己的虚拟地址空间的，也就说都有自己的页表。

那么， 108 个进程的话，就需要48BMB的内存来存储页表，这是非常大的内存了，更别说 64 位的环境了。

要解决上面的问题，就需要采用一种叫作多级页表(Multi-Level Page Table)的解决方案。

Q：分了二级表，映射 4GB 地址空间就需要 4KB(一级页表)+4MB(二级页表)的内存，这样占用空间不是更大了吗?

当然如果 4GB 的虚拟地址全部都映射到了物理内存上的话，二级分页占用空间确实是更大了，但是，我们往往不会为一个进程分配那么多内存。

其实我们应该换个角度来看问题，还记得计算机组成原理里面无处不在的局部性原理么?

每个进程都有 4GB 的虚拟地址空间，而显然对于大多数程序来说，其使用到的空间远未达到 4GB，因为会存在部分对应的页表项都是空的，根本没有分配，对于已分配的页表项，如果存在最近一定时间未访问的页表，在物理内存紧张的情况下，操作系统会将页面换出到硬盘，也就是说不会占用物理内存。

如果使用了二级分页，一级页表就可以覆盖整个 4GB 虚拟地址空间，但如果某个级页表的页表项没有被用到，也就不需要创建这个页表项对应的二级页表了，即可以在需要时才创建二级页表。做个简单的计算，假设只有 20%的一级页表项被用到了，那么页表占用的内存空间就只有 4KB(一级页表)+20%*4MB(二级页表)=8.884M8，这对比单级页表的4M是不是一个巨大的节约?

那么为什么不分级的页表就做不到这样节约内存呢?

我们从页表的性质来看，保存在内存中的页表承担的职责是将虚拟地址翻译成物理地址。假如虚拟地址在页表中找不到对应的页表项，计算机系统就不能工作了。所以页表一定要覆盖全部虚拟地址空间，不分级的页表就需要有 100 多万个页表项来映射，而二级分页则只需要 1024 个页表项(此时一级页表覆盖到了全部虚拟地址空间，二级页表在需要时创建)。

我们把二级分页再推广到多级页表，就会发现页表占用的内存空间更少了，这一切都要归功于对局部性原理的充分应用。

总结

为了在多进程环境下，使得进程之间的内存地址不受影响，相互隔离，于是操作系统就为每个进程独立分配一套虚拟地址空间，每个程序只关心自己的虚拟地址就可以，实际上大家的虚拟地址都是一样的，但分布到物理地址内存是不一样的。作为程序，也不用关心物理地址的事情。

每个进程都有自己的虚拟空间，而物理内存只有一个，所以当启用了大量的进程，物理内存必然会很紧张，于是操作系统会通过内存交换技术，把不常使用的内存暂时存放到硬盘(换出)，在需要的时候再装载回物理内存(换入)。

那既然有了虚拟地址空间，那必然要把虚拟地址「映射」到物理地址，这个事情通常由操作系统来维护。

那么对于虚拟地址与物理地址的映射关系，可以有分段和分页的方式，同时两者结合都是可以的。

内存分段是根据程序的逻辑角度，分成了栈段、堆段、数据段、代码段等，这样可以分离出不同属性的段，同时是一块连续的空间。但是每个段的大小都不是统一的，这就会导致外部内存碎片和内存交换效率低的问题。

于是，就出现了内存分页，把虚拟空间和物理空间分成大小固定的页，如在 Linux系统中，每一页的大小为 4KB。由于分了页后，就不会产生细小的内存碎片，解决了内存分段的外部内存碎片问题。同时在内存交换的时候，写入硬盘也就一个页或几个页，这就大大提高了内存交换的效率。

再来，为了解决简单分页产生的页表过大的问题，就有了多级页表，它解决了空间上的问题，但这就会导致 CPU 在寻址的过程中，需要有很多层表参与，加大了时间上的开销。于是根据程序的局部性原理，在CPU 芯片中加入了TLB，负责缓存最近常被访问的页表项，大大提高了地址的转换速度。

Linux 系统主要采用了分页管理，但是由于Intel 处理器的发展史，Linux 系统无法避免分段管理。于是 Linux 就把所有段的基地址设为8，也就意味着所有程序的地址空间都是线性地址空间(虚拟地址)，相当于屏蔽了CPU逻辑地址的概念，所以段只被用于访问控制和内存保护。

另外，Linux 系统中虚拟空间分布可分为用户态和内核态两部分，其中用户态的分布:代码段、全局变量、BSS、函数栈、堆内存、映射区。

最后，说下虚拟内存有什么作用?

第一，虚拟内存可以使得进程对运行内存超过物理内存大小，因为程序运行符合局部性原理，CPU访问内存会有很明显的重复访问的倾向性，对于那些没有被经常使用到的内存，我们可以把它换出到物理内存之外，比如硬盘上的 swap 区域。
第二，由于每个进程都有自己的页表，所以每个进程的虚拟内存空间就是相互独立的。进程也没有办法访问其他进程的页表，所以这些页表是私有的，这就解决了多进程之间地址冲突的问题。
第三，页表里的页表项中除了物理地址之外，还有一些标记属性的比特，比如控制一个页的读写权限，标记该页是否存在等。在内存访问方面，操作系统提供了更好的安全性。

4.2 malloc 是如何分配内存的?

实际上，malloc0 并不是系统调用，而是C库里的函数，用于动态分配内存。

malloc 申请内存的时候，会有两种方式向操作系统申请堆内存。

方式一:通过 brk0 系统调用从堆分配内存
方式二:通过 mmap0 系统调用在文件映射区域分配内存;

方式一实现的方式很简单，就是通过 brk0 函数将「堆顶」指针向高地址移动，获得新的内存空间。如下图:

方式二通过 mmap0 系统调用中「私有匿名映射」的方式，在文件映射区分配一块内存，也就是从文件映射区“偷"了一块内存。如下图:

Q：什么场景下 malloc0 会通过 brk0 分配内存?又是什么场景下通过mmap0 分配内存?

malloc() 源码里默认定义了一个阈值!

如果用户分配的内存小于 128 KB，则通过 brk0 申请内存;
如果用户分配的内存大于 128 KB，则通过 mmap0 申请内存;

注意，不同的 glibc 版本定义的阈值也是不同的。

Q：malloc()分配的是物理内存吗?

不是的，malloc()分配的是虚拟内存。

如果分配后的虚拟内存没有被访问的话，虚拟内存是不会映射到物理内存的，这样就不会占用物理内存了。只有在访问已分配的虚拟地址空间的时候，操作系统通过查找页表，发现虚拟内存对应的页没有在物理内存中，就会触发缺页中断，然后操作系统会建立虚拟内存和物理内存之间的映射关系。

Q：malloc(1)会分配多大的虚拟内存?

maloc() 在分配内存的时候，并不是老老实实按用户预期申请的字节数来分配内存空间大小，而是会预分配更大的空间作为内存池。

具体会预分配多大的空间，跟 malloc 使用的内存管理器有关系，我们就以 malloc默认的内存管理器(Ptmalloc2)来分析。

这个例子分配的内存小于 128 KB，所以是通过 brk0 系统调用向堆空间申请的内存，因此可以看到最右边有 [heap] 的标识。

可以看到，堆空间的内存地址范围是 00d73000-00d94000，这个范围大小是132KB，也就说明了 malloc(1)实际上预分配 132K 字节的内存,

Q：free 释放内存，会归还给操作系统吗?

通过 free 释放内存后，堆内存还是存在的，并没有归还给操作系统。

这是因为与其把这1字节释放给操作系统，不如先缓存着放进maloc 的内存池里当进程再次申请1字节的内存时就可以直接复用，这样速度快了很多。当然，当进程退出后，操作系统就会回收进程的所有资源。上面说的 free 内存后堆内存还存在，是针对 malloc 通过 brk0 方式申请的内存的情况。

如果 malloc 通过 mmap 方式申请的内存，free 释放内存后就会归归还给操作系统。

对于「malloc 申请的内存，free 释放内存会归还给操作系统吗？」这个问题，我们可以做个总结了：

malloc 通过 brk() 方式申请的内存，free 释放内存的时候，并不会把内存归还给操作系统，而是缓存在 malloc 的内存池中，待下次使用；
malloc 通过 mmap() 方式申请的内存，free 释放内存的时候，会把内存归还给操作系统，内存得到真正的释放。

Q：为什么不全部使用 mmap 来分配内存?

咱们来聊聊 ma11oc 为啥不一股脑儿全用 mmap 来分内存，非得搞个 brkmmap 的组合拳。这事儿吧，说白了就是性能和资源管理上的一种权衡，没有一招鲜吃遍天的好事儿。

你想啊， mmap 确实挺酷的，每次都能从操作系统那儿划拉一块全新的、独立的虚拟内存区域给你，用完了直接munmap 还回去，干干净净，碎片问题也少。但问题就在于，这“酷"是有代价的!每次调用 mmap，都得劳烦操作系统内核跑一趟，做一大堆事情:找个没人用的地址空间、设置好页表项、可能还要清空内存页(确保安全)、更新内核数据结构.. 这一套流程下来，开销可比在用户态捣鼓点指针大多了。要是你程序里动不动就分配释放一堆小块儿内存(比如链表节点、小对象啥的)，每次都来这么一趟mmap/munmap ，那性能可就真得慢得掉渣了，系统调用本身、TLB(快表)刷新的开销都能把你拖垮。

这时候 brk 的价值就体现出来了。它本质上是挪动一个叫“program break”的指针，把进程堆区的尾巴伸长或者缩短。分配小块内存时，ma11oc在用户空间自己管理堆区这块地盘就行了。它预先通过 brk扩大堆区(比如一次申请一大块)，然后在这块连续的内存里，像切豆腐一样，根据你的请求切出合适的小块给你。释放的时候呢，也不是立刻还给操作系统，而是记录起来(放进空闲链表之类的结构)，等下次有人再要小块内存时直接复用。只有当堆顶一大块连续内存都空闲了， ma11oc才可能用 brk把尾巴缩回去，把内存真正还给系统。这么搞，好处太明显了:对于大量、频繁的小内存申请释放，绝大部分操作都在用户态搞定，速度快得飞起，系统调用的开销被摊得非常薄。碎片问题虽然存在，但a11oc自己会努力合并相邻的空闲块来缓解。

当然， brk 也不是万金油。堆区是连续的，要是中间被零零碎碎的小块占着，即使总空闲空间够，也可能找不到一块连续的大空间来满足大内存申请(这就是内部碎片)。而且，堆区理论上只能向一个方向长(通常向上)，管理起来没那么灵活。

所以，malloc的智慧就在于“看人下菜碟”:

小内存、频繁请求:主要靠 brk 管理的堆区。用户态搞定，速度快如闪电。
大内存(通常超过一个阈值，比如几百KB):直接用单独映射一块。这mmap样避免了在堆区造成难以忍受的大洞(外部碎片)，释放时也能干净利落地立刻归还给系统，不拖累堆区。

总结起来就是:灵活干净但开销大，brk管理堆速度快但对大块和碎片敏mmap感。 ma11oc 混着用，让小内存分配享受 brk的速度红利，让大内存分配享受mmap 的独立与干净，各取所长，才能在各种内存分配需求下都交出比较均衡、高效的答卷。

要是全用 mmap ，小内存分配的频繁开销会让程序慢得怀疑人生，要是全用brk，遇上大内存或者长期运行产生大量碎片，程序可能就“卡死"在明明有内存却分配不出来的尴尬境地。所以，这个组合拳，打得有理!

Q：既然 brk 那么牛逼，为什么不全部使用 brk 来分配?

前面我们提到通过 brk 从堆空间分配的内存，并不会归还给操作系统。

因此，随着系统频繁地 malloc 和 free ，尤其对于小块内存，堆内将产生越来越多不可用的碎片，导致“内存泄露”。而这种“泄露"现象使用 valgrind(内测泄漏检测工具) 是无法检测出来的。所以，malloc 实现中，充分考虑了 brk和 mmap 行为上的差异及优缺点，默认分配大块内存(128KB) 才使用 mmap 分配内存空间。

Q：free() 函数只传入一个内存地址，为什么能知道要释放多大的内存?

还记得，我前面提到，malloc 返回给用户态的内存起始地址比进程的堆空间起始地址多了 16 字节吗?

这个多出来的 16 字节就是保存了该内存块的描述信息，比如有该内存块的大小。

这样当执行 free0 函数时，free 会对传入进来的内存地址向左偏移 16 字节，然后从这个 16 字节的分析出当前的内存块的大小，自然就知道要释放多大的内存了。

Q：malloc内存分配器是怎样实现的?

面试官:malloc内存分配器是怎样实现的?

4.3 内存满了，会发生什么?

Q：虚拟内存有什么作用?

第一，虚拟内存可以使得进程对运行内存超过物理内存大小，因为程序运行符合局部性原理，CPU 访问内存会有很明显的重复访问的倾向性，对于那些没有被经常使用到的内存，我们可以把它换出到物理内存之外，比如硬盘上的 swap 区域。
第二，由于每个进程都有自己的页表，所以每个进程的虚拟内存空间就是相互独立的。进程也没有办法访问其他进程的页表，所以这些页表是私有的，这就解决了多进程之间地址冲突的问题。
第三，页表里的页表项中除了物理地址之外，还有一些标记属性的比特，比如控制一个页的读写权限，标记该页是否存在等。在内存访问方面，操作系统提供了更好的安全性。

Q：内存分配的过程是怎样的?

应用程序通过 maloc 函数申请内存的时候，实际上申请的是虚拟内存，此时并不会分配物理内存。当应用程序读写了这块虚拟内存，CPU 就会去访问这个虚拟内存，这时会发现这个虚拟内存没有映射到物理内存， CPU 就会产生缺页中断，进程会从用户态切换到内核态，并将缺页中断交给内核的 Page FaultHandler(缺页中断函数)处理。缺页中断处理函数会看是否有空闲的物理内存，如果有，就直接分配物理内存，并建立虚拟内存与物理内存之间的映射关系。如果没有空闲的物理内存，那么内核就会开始进行回收内存的工作，回收的方式主要是两种:直接内存回收和后台内存回收。

后台内存回收(kswapd):在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这个回收内存的过程异步的，不会阻塞进程的执行。
直接内存回收(direct reclaim):如果后台异步回收跟不上进程内存申请的速度，就会开始直接回收，这个回收内存的过程是同步的，会阻塞进程的执行。

如果直接内存回收后，空闲的物理内存仍然无法满足此次物理内存的申请，那么内核就会放最后的大招了触发 OOM (out of Memory)机制。 OOM Killer 机制会根据算法选择一个占用物理内存较高的进程，然后将其杀死，以便释放内存资源，如果物理内存依然不足，OOM Kier 会继续杀死占用物理内存较高的进程，直到释放足够的内存位置。

Q：哪些内存可以被回收?

系统内存紧张的时候，就会进行回收内存的工作，那具体哪些内存是可以被回收的呢?

主要有两类内存可以被回收，而且它们的回收方式也不同。

文件页(File-backed Page):内核缓存的磁盘数据(Buffer)和内核缓存的文件数据(Cache)都叫作文件页。大部分文件页，都可以直接释放内存，以后有需要时，再从磁盘重新读取就可以了。而那些被应用程序修改过，并且暂时还没写入磁盘的数据(也就是脏页)，就得先写入磁盘，然后才能进行内存释放。所以，回收干净页的方式是直接释放内存，回收脏页的方式是先写回磁盘后再释放内存。- 匿名页(Anonymous Page):这部分内存没有实际载体，不像文件缓存有硬盘文件这样一个载体，比如堆、栈数据等。这部分内存很可能还要再次被访问，所以不能直接释放内存，它们回收的方式是通过Linux 的 Swap 机制，Swap 会把不常访问的内存先写到磁盘中，然后释放这些内存，给其他更需要的进程使用。再次访问这些内存时，重新从磁盘读入内存就可以了。

文件页和匿名页的回收都是基于 LRU 算法，也就是优先回收不常访问的内存。LRU 回收算法，实际上维护着 active 和 inactive 两个双向链表，其中:

active list 活跃内存页链表，这里存放的是最近被访问过(活跃)的内存页;
inactive list 不活跃内存页链表，这里存放的是很少被访问(非活跃)的内存页; 越接近链表尾部，就表示内存页越不常访问。这样，在回收内存时，系统就可以根据活跃程度，优先回收不活跃的内存。

Q：回收内存带来的性能影响？

在前面我们知道了回收内存有两种方式。

一种是后台内存回收，也就是唤醒 kswapd 内核线程，这种方式是异步回收的，不会阻塞进程。
一种是直接内存回收，这种方式是同步回收的，会阻塞进程，这样就会造成很长时间的延迟，以及系统的 CPU 利用率会升高，最终引起系统负荷高。可被回收的内存类型有文件页和匿名页:
文件页的回收:对于干净页是直接释放内存，这个操作不会影响性能，而对于脏页会先写回到磁盘再释放内存，这个操作会发生磁盘 //0 的，这个操作是会影响系统性能的。
匿名页的回收:如果开启了 Swap 机制，那么 Swap 机制会将不常访问的匿名页换出到磁盘中，下次访问时，再从磁盘换入到内存中，这个操作是会影响系统性能的。可以看到，回收内存的操作基本都会发生磁盘 /0 的，如果回收内存的操作很频繁，意味着磁盘 1/0 次数会很多，这个过程势必会影响系统的性能，整个系统给人的感觉就是很卡。

Q：下面针对回收内存导致的性能影响，说说常见的解决方式？

调整文件页和匿名页的回收倾向从文件页和匿名页的回收操作来看，文件页的回收操作对系统的影响相比匿名页的回收操作会少一点，因为文件页对于干净页回收是不会发生磁盘 !/0 的，而匿名页的 Swap 换入换出这两个操作都会发生磁盘I/O.

Linux 提供了一个 /proc/sys/vm/swappiness 选项，用来调整文件页和匿名页的回收倾向。 swappiness 的范围是 0-100，数值越大，越积极使用 Swap，也就是更倾向于回收匿名页;数值越小，越消极使用 Swap，也就是更倾向于回收文件页。

一般建议 swappiness 设置为0(默认值是 60)，这样在回收内存的时候，会更倾向于文件页的回收，但是并不代表不会回收匿名页。

尽早触发 kswapd 内核线程异步回收内存

我们可以使用 sar -81 命令来观察:

图中红色框住的就是后台内存回收和直接内存回收的指标，它们分别表示:

pgscank/s:kswapd(后台回收线程)每秒扫描的 page 个数。
pgscand/s: 应用程序在内存申请过程中每秒直接扫描的 page 个数。
pgsteal/s: 扫描的 page 中每秒被回收的个数(pgscank+pgscand)。如果系统时不时发生抖动，并且在抖动的时间段里如果通过 sar -8 观察到 pgscand 数值很大，那大概率是因为「直接内存回收」导致的。针对这个问题，解决的办法就是，可以通过尽早的触发「后台内存回收」来避免应用程序进行直接内存回收。

Q：什么条件下才能触发 kswapd 内核线程回收内存呢?

内核定义了三个内存阈值(watermark，也称为水位)，用来衡量当前剩余内存(pages_free)是否充裕或者紧张，分别是: 页最小阈值(pages_min); 页低阈值(pages_low); 页高阈值(pages_high); 这三个内存阈值会划分为四种内存使用情况，如下图:

kswapd 会定期扫描内存的使用情况，根据剩余内存(pages_free)的情况来进行内存回收的工作。

图中绿色部分:如果剩余内存(pages_free)大于页高阈值(pages_high)，说明剩余内存是充足的;中匳威外办的孩撓閾掣坷浏究
图中蓝色部分:如果剩余内存(pages_free)在页高阈值(pages_high)和页低阈值(pages_low)之间，说明内存有一定压力，但还可以满足应用程序申请内存的请求;
图中橙色部分:如果剩余内存(pages_free)在页低值(pages_low)和页最小值(pages_min)之间，说明内存压力比较大，剩余内存不多了。这时kswapd0 会执行内存回收，直到剩余内存大于高阈值(pages_high)为止。虽然会触发内存回收，但是不会阻塞应用程序，因为两者关系是异步的。
图中红色部分:如果剩余内存(pages_free)小于页最小闽值(pages_min)，说明用户可用内存都耗尽了，此时就会触发直接内存回收，这时应用程序就会被阻塞，因为两者关系是同步的。

可以看到，当剩余内存页(pages_free)小于页低阈值(pages_ow)，就会触发 kswapd 进行后台回收,然后 kswapd 会一直回收到剩余内存页(pages_free)大于页高阈值(pages _high)。也就是说 kswapd 的活动空间只有 pages low 与 pages min 之间的这段区域，如果剩余内存低于了 pages_min 会触发直接内存回收，高于了 pages high 又不会唤醒 kswapd。页低阈值(pages low)可以通过内核选项 /proc/sys/vm/min_free_kbytes(该参数代表系统所保留空闲内存的最低限)来间接设置。 min_free_kbytes 虽然设置的是页最小阈值(pages_min)，但是页高阈值(pages_high)和页低阈值(pages_ow)都是根据页最小阈值(pages_min)计算生成的，它们之间的计算关系如下:

pages min = min free kbytes
pages low= pages min*5/4
pages high = pages min*3/2

如果系统时不时发生抖动，并且通过 sar -8 观察到 pgscand 数值很大，那大概率是因为直接内存回收导致的，这时可以增大 min _free_kbytes 这个配置选项来及早地触发后台回收，然后继续观察 pgscand 是否会降为 0。

增大了 min free kbytes 配置后，这会使得系统预留过多的空闲内存，从而在一定程度上降低了应用程序可使用的内存量，这在一定程度上浪费了内存。极端情况下设置 min free kbvtes 接近实际物理内存大小时，留给应用程序的内存就会太少而可能会频繁地导致 OOM 的发生。

所以在调整 min_free_kbytes 之前，需要先思考一下，应用程序更加关注什么，如果关注延迟那就适当地增大 min_free_kbytes，如果关注内存的使用量那就适当地调小 min_free_kbytes。

Q：什么是 NUMA 架构?

SMP 指的是一种多个CPU 处理器共享资源的电脑硬件架构，也就是说每个 CPU 地位平等，它们共享相同的物理资源，包括总线、内存、10、操作系统等。每个CPU 访问内存所用时间都是相同的，因此，这种系统也被称为一致存储访问结构(UMA，Uniform Memory Access)。

随着 CPU 处理器核数的增多，多个CPU 都通过一个总线访问内存，这样总线的带宽压力会越来越大，同时每个 CPU 可用带宽会减少，这也就是 SMP 架构的问题。

为了解决 SMP 架构的问题，就研制出了 NUMA 结构，即非一致存储访问结构(Non-uniform memoryaccess，NUMA)。

NUMA 架构将每个 CPU 进行了分组，每一组 CPU 用 Node 来表示，一个 Node 可能包含多个 CPU 。

每个 Node 有自己独立的资源，包括内存、10 等，每个 Node 之间可以通过互联模块总线(QPI)进行通信，所以，也就意味着每个 Node 上的 CPU 都可以访问到整个系统中的所有内存。但是，访问远端 Node的内存比访问本地内存要耗时很多。

Q：NUMA 架构跟回收内存有什么关系?

在 NUMA 架构下，当某个 Node 内存不足时，系统可以从其他 Node 寻找空闲内存，也可以从本地内存中回收内存。具体选哪种模式，可以通过 /proc/sys/vm/zone_reclaim_mode 来控制。它支持以下几个选项

0(默认值):在回收本地内存之前，在其他Node 寻找空闲内存;
1:只回收本地内存;
2:只回收本地内存，在本地回收内存时，可以将文件页中的脏页写回硬盘，以回收内存。
4:只回收本地内存，在本地回收内存时，可以用 swap 方式回收内存。在使用 NUMA 架构的服务器，如果系统出现还有一半内存的时候，却发现系统频繁触发「直接内存回收」，导致了影响了系统性能，那么大概率是因为 zone_reclaim mode 没有设置为0，导致当本地内存不足的时候，只选择回收本地内存的方式，而不去使用其他 Node 的空闲内存。虽然说访问远端 Node 的内存比访问本地内存要耗时很多，但是相比内存回收的危害而言，访问远端Node 的内存带来的性能影响还是比较小的。因此，zone_reclaim_mode 一般建议设置为 0。

Q：如何保护一个进程不被 OOM 杀掉呢?

在系统空闲内存不足的情况，进程申请了一个很大的内存，如果直接内存回收都无法回收出足够大的空闲内存，那么就会触发 OOM 机制，内核就会根据算法选择一个进程杀掉。 Linux 到底是根据什么标准来选择被杀的进程呢?这就要提到一个在 Linux内核里有一个 oom badness()函数，它会把系统中可以被杀掉的进程扫描一遍，并对每个进程打分，得分最高的进程就会被首先杀掉。进程得分的结果受下面这两个方面影响: 第一，进程已经使用的物理内存页面数。第二，每个进程的 OOM 校准值 oom_score_adj。它是可以通过 /proc/[pid]/oom_score_adj 来配置的。我们可以在设置 -1000 到 1000 之间的任意一个数值，调整进程被 OOM Kil 的几率。函数 oom badness0) 里的最终计算方法是这样的:

// points 代表打分的结果
//process_pages 代表进程已经使用的物理内存页面数
//oom score adj 代表 00M 校准值
//totalpages 代表系统总的可用页面数
points =process pages + oom score adj*totalpages/1000

用「系统总的可用页面数」乘以「OOM 校准值 oom_score_adj」再除以 1000，最后再加上进程已经使用的物理页面数，计算出来的值越大，那么这个进程被 OOM Ki 的几率也就越大。每个进程的 oom_score_adj默认值都为 0，所以最终得分跟进程自身消耗的内存有关，消耗的内存越大越容易被杀掉。我们可以通过调整 oom_score_adj 的数值，来改成进程的得分结果:

如果你不想某个进程被首先杀掉，那你可以调整该进程的oom_score_adj，从而改变这个进程的得分结果，降低该进程被 OOM 杀死的概率。
如果你想某个进程无论如何都不能被杀掉，那你可以将 oom_score_adj 配置为 -1000。我们最好将一些很重要的系统服务的 oom_score_adj配置为 -1000，比如 sshd，因为这些系统服务一旦被杀掉，我们就很难再登陆进系统了。但是，不建议将我们自己的业务程序的 oom_score_adi 设置为 -1000，因为业务程序一旦发生了内存泄漏，而它又不能被杀掉，这就会导致随着它的内存开销变大，OOM kiler 不停地被唤醒，从而把其他进程一个个给杀掉。

总结

内核在给应用程序分配物理内存的时候，如果空闲物理内存不够，那么就会进行内存回收的工作，主要有两种方式:

后台内存回收:在物理内存紧张的时候，会唤醒 kswapd 内核线程来回收内存，这个回收内存的过程异. 步的，不会阻塞进程的执行。
直接内存回收:如果后台异步回收跟不上进程内存申请的速度，就会开始直接回收，这个回收内存的过程是同步的，会阻塞进程的执行。可被回收的内存类型有文件页和匿名页:
文件页的回收:对于干净页是直接释放内存，这个操作不会影响性能，而对于脏页会先写回到磁盘再释放内存，这个操作会发生磁盘 I/0 的，这个操作是会影响系统性能的。
匿名页的回收:如果开启了 Swap 机制，那么 Swap 机制会将不常访问的匿名页换出到磁盘中，下次访问时，再从磁盘换入到内存中，这个操作是会影响系统性能的。

文件页和匿名页的回收都是基于 LRU 算法，也就是优先回收不常访问的内存。回收内存的操作基本都会发生磁盘 I/0 的，如果回收内存的操作很频繁，意味着磁盘 V0 次数会很多，这个过程势必会影响系统的性能。

针对回收内存导致的性能影响，常见的解决方式。

设置 /proc/sys/vm/swappiness，调整文件页和匿名页的回收倾向，尽量倾向于回收文件页;
设置 /proc/sys/vm/min_free_kbytes，调整 kswapd 内核线程异步回收内存的时机;
设置 /proc/sys/vm/zone_reclaim_mode，调整 NUMA 架构下内存回收策略，建议设置为 0，这样在回收本地内存之前，会在其他 Node 寻找空闲内存，从而避免在系统还有很多空闲内存的情况下，因本地Node 的本地内存不足，发生频繁直接内存回收导致性能下降的问题;

在经历完直接内存回收后，空闲的物理内存大小依然不够，那么就会触发 OOM 机制，OOM killer 就会根据每个进程的内存占用情况和 oom_score_adj 的值进行打分，得分最高的进程就会被首先杀掉。

我们可以通过调整进程的 /proc/[pid]/oom_score_adj 值，来降低被 OOM kiler 杀掉的概率。