Toki

小林系统内存管理

虚拟内存概述
malloc
1. GNU malloc 策略
2. block header
物理内存不够了怎么办？
4GB物理内存机器上申请8GB内存
预读失效和缓存污染：改进LRU
1. 预读失效
2. 缓存污染

虚拟内存概述

虚拟内存为程序提供了强隔离性，并基于保护了各个程序。

应用程序不直接读写物理内存，而是每个内存都有独立的虚拟地址空间，虚拟地址被映射到物理地址进行使用
基本映射方式有两种：分段和分页

内存分段

va = 段号+偏移量，段号索引段表中的一个段项，段项包含了该段实际的起始物理地址、权限、段大小等

将程序的虚拟地址分为四个分别物理连续的段：代码+数据+堆+栈，每个段在段表中都有一个段项

这并不会导致内部内存碎片的问题，但会有外部内存碎片的问题。例如新的程序的一个段有200MB，但这里插不下：

为了解决这个问题，只好重排内存，把一部分内存写入磁盘，然后重写加载到合适的位置，减少内存碎片，也即 内存交换

对于多进程的系统，很容易产生外部内存碎片，从而反复地进行 swap，产生了大量浪费——且磁盘非常慢，严重拖慢整个系统的速度

内存分页

概述

将虚拟 & 物理内存划分为一个个固定大小的区域进行映射，称为页，通常一页大小为4KB
通过 页表 进行va和pa的转换，每一个映射项称为PTE
转换过程通过硬件 MMU 完成，MMU有缓存 TLB，可以缓存PTE，并在切换页表时清空缓存

页表

内核使用一个页来存放页表，每个PTE 8B，每个页表512个PTE。
页表必须覆盖每个进程的所有虚拟地址空间，但这会导致占用内存过大，于是出现了多级页表，不使用的地址部分的PT我们可以不分配，只需要覆盖程序实际使用的部分即可

例如这是一个四级页表，va=四个页号+实际数据页的offset

内存碎片与内存交换

分页使得各个页紧密排布，没有外部内存碎片，但有内部内存碎片——程序没用完这一页。
当物理内存不够时，内核会把一部分页 swap out 到磁盘上，在需要使用时再 swap in 加载回来——每次只写一部分页，很高效
更进一步的想，这还允许我们实现 lazy allocation、cow、mmap 等等机制

分段+分页

有的系统结合了两个机制，先把程序分段，然后每个段映射为多个页

每次使用地址都需要大量的查表操作，极为缓慢

Linux 内存布局

早期intel处理器使用段式内存管理，后来就全是页式内存管理了。早期的处理器只能使用分段+分页混合式布局。目前的分段机制几乎只是为了兼容，Linux 为此将整个程序使用的部分分为一个虚拟段，然后用分页机制映射

很多内核对自己的地址空间和物理空间做了 恒等映射，这样可以通过操纵虚拟地址的方式直接操纵物理地址

用户地址空间大多分布如下：

malloc

malloc() 并不是系统调用，而是 C 库里的函数，用于动态分配内存。

分配器持有一片连续的内存，这个区域叫堆。每次以 block 为单位分配内存，block 需要满足字对齐要求，这些内存都是 虚拟内存

每次被 free 的block会被归还给这个分配器，而不是还给OS。mmap分配的 block 会还给OS

GNU malloc 策略

分段链表/分区堆：每种类型大小的链表的内存块大小都一样，采用 first-fit 分配内存块，使用 brk 增长堆
过大的内存就不用堆了，而是用 mmap 在内存映射文件区域映射一个匿名文件

不全部使用mmap的原因是，系统调用会消耗大量的时间。mmap可能以cow的方式实现，这会触发handler，进行上下文切换，也需要耗费大量的时间

不全部使用 sbrk 的原因是，可能出现大块内存碎片的问题

block header

分配的每个 block 都有一个 header，里面可能存储一些元数据，比如块大小、块是否被分配、上一个/下一个块是否被分配、指向下一个块的指针等等

物理内存不够了怎么办？

OS通常都实现了 COW 机制，也就是说申请的虚拟内存只有在你读写的时候才触发 page fault，调用相应的 handler，并分配实际的物理内存，改写页表

这时候你发现物理页不够了。系统会进行以下尝试以找到足够的物理内存：

内存回收 & OOM：内存不够怎么办

内存回收

文件缓存：直接丢弃（脏页可能需要先写入磁盘）
匿名页：LRU 写入磁盘 swap
使用时再从磁盘加载回来

磁盘速度缓慢，会影响整个系统的性能，发生

有两个list存放着活跃和不活跃的内存页链表：active_list & inactive_list。

可以查询它们的大小：活跃/不活跃，匿名/不匿名两两组合

系统的机制如下：

系统在检测到内存压力时，会启用后台内存回收机制，通过一个内核线程 kswapd 进行异步回收内存
如果内存此时不够，会启用直接内存回收机制，阻塞当前进程尝试 同步回收内存

OOM Killer

这时候要是内存还是不够，系统会根据算法选择并强制杀死一个物理内存占用较高的进程，直到有足够的物理内存

如何减轻回收内存带来的影响？

调整 swap 倾向

匿名页的回收全都要用到 swap，发生磁盘I/O，而文件页中除了脏页不需要 swap，通过更多的回收文件页，我们减少swap的使用

Linux 有一个 swapiness 选项可以调整回收匿名页的倾向

水位线机制：频繁进行直接内存回收怎么解决？

Linux 内核使用了水位线机制：

在空闲pages低于 low 时开启后台内存回收机制，直到水位线回升至 high
在水位线降至 min 时开启直接内存回收机制
要是继续降低，比如达到min的百分之十，则会开启 OOM Killer

Linux 中的 pages_min 叫 min_free_kbytes，其他的水位线根据 min 计算出来，也可以自由调整

可以通过 sar -B 1 查看内存回收指标：

pgscank/s：每秒后台扫描的页数（扫描不等于回收）
pgscand/s：每秒直接扫描的页数（扫描不等于回收）
pgsteal/s：每秒实际回收的个数（后台+直接回收）

如果pgscand太大，通过增大min，可以提前触发后台内存回收，从而降低直接内存回收触发频率。但这会降低系统的速度，带来一定的延迟

如果将最低阈值设置的太低，可能导致频繁触发OOM。

NUMA 架构下的内存回收策略

SMP 又称为 UMA Uniform Memory Access 一致存储访问结构，每个CPU共享相同的物理资源。随着CPU的增多，总线压力越来越大，每个CPU的平均总线带宽会减少

而 NUMA Not UMA 则对CPU进行了分组，每个分组称为一个Node 节点，共享相同的物理资源，节点之间可以通过 QPI 互联模块总线进行通信

当一个节点的内存不足了，其内存回收策略有：

回收本地内存前，偷取远程节点的内存。慢但比内存回收快
回收本地内存
回收本地内存 + 写脏页
回收本地内存 + swap

对于NUMA架构的服务器，如果系统内存还有一半，某个节点却触发了内存回收，则可以调整他的策略，从远程节点共享内存

OOM 算法

在触发OOM时，Linux 有一个函数 oom_badness()，它会扫描所有可以被杀死的进程，为他们打分，分数最高的进程被杀死。打分算法如下：

可以通过配置校准值 到 -1000~1000 中的一个值，从而减少进程被杀死的概率

默认情况下，进程的校准值为0，也就是只根据使用的物理页数打分

我们最好将一些很重要的系统服务的 oom_score_adj 配置为 -1000，比如 sshd，因为这些系统服务一旦被杀掉，我们就很难再登陆进系统了。
但是，不建议将我们自己的业务程序的 oom_score_adj 设置为 -1000，因为业务程序一旦发生了内存泄漏，而它又不能被杀掉，这就会导致随着它的内存开销变大，OOM killer 不停地被唤醒，从而把其他进程一个个给杀掉。