一、前言
在工作生活中，我们时常会遇到一些性能问题：比如手机用久了，在滑动窗口或点击 APP 时会出现页面反应慢、卡顿等情况；比如运行在某台服务器上进程的某些性能指标（影响用户体验的 PCT99 指标等）不达预期，产生告警等；造成性能问题的原因多种多样，可能是网络延迟高、磁盘 IO 慢、调度延迟高、内存回收等，这些最终都可能影响到用户态进程，进而被用户感知。
在 Linux 服务器场景中，内存是影响性能的主要因素之一，本文从内存管理的角度，总结归纳了一些常见的影响因素（比如内存回收、Page Fault 增多、跨 NUMA 内存访问等），并介绍其对应的调优方法。
二、内存回收
2.1什么是内存
内存(Memory)是计算机的重要部件之一，也称内存储器和主存储器，它用于暂时存放CPU中的运算数据，与硬盘等外部存储器交换的数据。
它是外存与CPU进行沟通的桥梁，计算机中所有程序的运行都在内存中进行，内存性能的强弱影响计算机整体发挥的水平。
只要计算机开始运行，操作系统就会把需要运算的数据从内存调到CPU中进行运算，当运算完成，CPU将结果传送出来。
内存的运行也决定计算机整体运行快慢的程度。
2.2Linux内存回收机制
为啥要回收：
- 内核需要为任何时刻突发到来的内存申请提供足够的内存，以便cache的使用和其他相关内存的使用不至于让系统的剩余内存长期处于很少的状态。
- 当真的有大于空闲内存的申请到来的时候，会触发强制内存回收。
内存回收针对的目标有两种，一种是针对zone的，另一种是针对一个memcg的，把针对zone的内存回收方式分为三种，分别是快速内存回收、直接内存回收、kswapd内存回收。
在整机层面，设置了三条水线：min、low、high；当系统 free 内存到 low 水线以下时，系统会唤醒kswapd 线程进行异步内存回收，一直回收到 high 水线为止，这种情况不会阻塞正在进行内存分配的进程；但如果 free 内存降到了 min 水线以下，就需要阻塞内存分配进程进行回收，不然就有 OOM（out of memory）的风险，这种情况下被阻塞进程的内存分配延迟就会提高，从而感受到卡顿。
图 1. per-zone watermark
这些水线可以通过内核提供的 /proc/sys/vm/watermark_scale_factor 接口来进行调整，该接口 合法取值的范围为 [0, 1000]，默认为 10，当该值设置为 1000 时，意味着 low 与 min 水线，以及 high 与 low 水线间的差值都为总内存的 10% (1000/10000)。
针对 page cache 型的业务场景，我们可以通过该接口抬高 low 水线，从而更早的唤醒 kswapd 来进行异步的内存回收，减少 free 内存降到 min 水线以下的概率，从而避免阻塞到业务进程，以保证影响业务的性能指标。
在 memory cgroup 层面，目前内核没有设置水线的概念，当内存使用达到 memory cgroup 的内存限制后，会阻塞当前进程进行内存回收。不过内核在 v5.19内核 中为 memory cgroup提供了 memory.reclaim 接口，用户可以向该接口写入想要回收的内存大小，来提早触发 memory cgroup 进行内存回收，以避免阻塞 memory cgroup 中的进程。
查看Linux内存情况
查看/proc/meminfo
[root@test ~]# cat /proc/meminfo MemTotal: 16166688 kB MemFree: 14051412 kB MemAvailable: 14772588 kB Buffers: 2116 kB Cached: 1073260 kB SwapCached: 0 kB Active: 770384 kB Inactive: 698264 kB Active(anon): 450156 kB Inactive(anon): 76748 kB Active(file): 320228 kB Inactive(file): 621516 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 33554428 kB SwapFree: 33554428 kB Dirty: 476 kB Writeback: 0 kB AnonPages: 393328 kB Mapped: 153828 kB Shmem: 133628 kB Slab: 246448 kB SReclaimable: 133892 kB SUnreclaim: 112556 kB KernelStack: 13472 kB PageTables: 30496 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 41637772 kB Committed_AS: 4257776 kB VmallocTotal: 34359738367 kB VmallocUsed: 320696 kB VmallocChunk: 34350426108 kB HardwareCorrupted: 0 kB AnonHugePages: 155648 kB CmaTotal: 0 kB CmaFree: 0 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 279276 kB DirectMap2M: 6965248 kB DirectMap1G: 11534336 kB
使用free命令查看
[root@test ~]# free -h total used free shared buff/cache available Mem: 15G 874M 13G 130M 1.2G 14G Swap: 31G 0B 31G
参数说明：
- total：总内存大小。
- used：已经使用的内存大小（这里面包含cached和buffers和shared部分）。
- free：空闲的内存大小。
- shared：进程间共享内存（一般不会用，可以忽略）。
- buffers：内存中写完的东西缓存起来，这样快速响应请求，后面数据再定期刷到磁盘上。
- cached：内存中读完缓存起来内容占的大小（这部分是为了下次查询时快速返回）。
- available：还可以被应用程序使用的物理内存大小，和free的区别是，free是真正未被使用的内存，available是包括buffers、cached的。
- Swap：硬盘上交换分区的使用大小。
Buffer和Cache
通过free或者top命令我们可以发现其将内存分为了buffer和cache等部分。Buffer 和 Cache 的设计目的，是为了提升系统的 I/O 性能。它们利用内存，充当起慢速磁盘与快速 CPU 之间的桥梁，可以加速 I/O 的访问速度。通过man free可以查阅到下面的说明
buffers Memory used by kernel buffers (Buffers in /proc/meminfo) cache Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)
Buffers 是内核缓冲区用到的内存，对应的是 /proc/meminfo 中的 Buffers 值。
Cache 是内核页缓存和 Slab 用到的内存，对应的是 /proc/meminfo 中的 Cached 与 SReclaimable 之和。
进一步通过man proc，可以看到具体说明：
Buffers %lu Relatively temporary storage for raw disk blocks that shouldn't get tremendously large (20MB or so). Cached %lu In-memory cache for files read from the disk (the page cache). Doesn't include SwapCached. SReclaimable %lu (since Linux 2.6.19) Part of Slab, that might be reclaimed, such as caches. SUnreclaim %lu (since Linux 2.6.19) Part of Slab, that cannot be reclaimed on memory pressure.
Buffers 是对原始磁盘块的临时存储，也就是用来缓存磁盘的数据，通常不会特别大（20MB 左右）。这样，内核就可以把分散的写集中起来，统一优化磁盘的写入，比如可以把多次小的写合并成单次大的写等等。
Cached 是从磁盘读取文件的页缓存，也就是用来缓存从文件读取的数据。这样，下次访问这些文件数据时，就可以直接从内存中快速获取，而不需要再次访问缓慢的磁盘。
SReclaimable 是 Slab 的一部分。Slab 包括两部分，其中的可回收部分，用 SReclaimable 记录；而不可回收部分，用 SUnreclaim 记录。
最终总结：Buffer 是对磁盘数据的缓存，而 Cache 是文件数据的缓存，它们既会用在读请求中，也会用在写请求中。
从写的角度来说，不仅可以优化磁盘和文件的写入，对应用程序也有好处，应用程序可以在数据真正落盘前，就返回去做其他工作。
从读的角度来说，不仅可以提高那些频繁访问数据的读取速度，也降低了频繁 I/O 对磁盘的压力。
三、Huge Page
内存作为宝贵的系统资源，一般都采用延迟分配的方式，应用程序第一次向分配的内存写入数据的时候会触发 Page Fault，此时才会真正的分配物理页，并将物理页帧填入页表，从而与虚拟地址建立映射。
此后，每次 CPU 访问内存，都需要通过 MMU 遍历页表将虚拟地址转换成物理地址。为了加速这一过程，一般都会使用 TLB（Translation-Lookaside Buffer）来缓存虚拟地址到物理地址的映射关系，只有 TLB cache miss 的时候，才会遍历页表进行查找。
页的默认大小一般为 4K， 随着应用程序越来越庞大，使用的内存越来越多，内存的分配与地址翻译对性能的影响越加明显。试想，每次访问新的 4K 页面都会触发 Page Fault，2M 的页面就需要触发 512 次才能完成分配。
另外 TLB cache 的大小有限，过多的映射关系势必会产生 cacheline 的冲刷，被冲刷的虚拟地址下次访问时又会产生 TLB miss，又需要遍历页表才能获取物理地址。
对此，Linux 内核提供了大页机制。 上图的 4 级页表中，每个 PTE entry 映射的物理页就是 4K，如果采用 PMD entry 直接映射物理页，则一次 Page Fault 可以直接分配并映射 2M 的大页，并且只需要一个 TLB entry 即可存储这 2M 内存的映射关系，这样可以大幅提升内存分配与地址翻译的速度。
因此，一般推荐占用大内存应用程序使用大页机制分配内存。当然大页也会有弊端：比如初始化耗时高，进程内存占用可能变高等。可以使用 perf 工具对比进程使用大页前后的 PageFault 次数的变化：
perf stat -e page-faults -p <pid> -- sleep 5
目前内核提供了两种大页机制，一种是需要提前预留的静态大页形式，另一种是透明大页(THP, Transparent Huge Page) 形式。
3.1 静态大页
首先来看静态大页，也叫做 HugeTLB。静态大页可以设置 cmdline 参数在系统启动阶段预留，比如指定大页 size 为 2M，一共预留 512 个这样的大页：
hugepagesz=2M hugepages=512
还可以在系统运行时动态预留，但该方式可能因为系统中没有足够的连续内存而预留失败。
- 预留默认 size（可以通过 cmdline 参数 default_hugepagesz=指定size）的大页：
echo 20 > /proc/sys/vm/nr_hugepages
预留特定 size 的大页：
echo 5 > /sys/kernel/mm/hugepages/hugepages-*/nr_hugepages
预留特定 node 上的大页：
echo 5 > /sys/devices/system/node/node*/hugepages/hugepages-*/nr_hugepages
当预留的大页个数小于已存在的个数，则会释放多余大页（前提是未被使用） 。
编程中可以使用 mmap(MAP_HUGETLB) 申请内存。
这种大页的优点是一旦预留成功，就可以满足进程的分配请求，还避免该部分内存被回收；缺点是：
- 需要用户显式地指定预留的大小和数量
- 需要应用程序适配，比如：
- mmap、shmget 时指定 MAP_HUGETLB；
- 挂载 hugetlbfs，然后 open 并 mmap
当然也可以使用开源 libhugetlbfs.so，这样无需修改应用程序
预留太多大页内存后，free 内存大幅减少，容易触发系统内存回收甚至 OOM
紧急情况下可以手动减少 nr_hugepages，将未使用的大页释放回系统；也可以使用 v5.7 引入的HugeTLB + CMA 方式，细节读者可以自行查阅。
3.2 透明大页
再来看透明大页，在 THP always 模式下，会在 Page Fault 过程中，为符合要求的 vma 尽量分配大页进行映射；如果此时分配大页失败，比如整机物理内存碎片化严重，无法分配出连续的大页内存，那么就会 fallback 到普通的 4K 进行映射，但会记录下该进程的地址空间 mm_struct；然后 THP 会在后台启动khugepaged 线程，定期扫描这些记录的 mm_struct，并进行合页操作。因为此时可能已经能分配出大页内存了，那么就可以将此前 fallback 的 4K 小页映射转换为大页映射，以提高程序性能。整个过程完全不需要用户进程参与，对用户进程是透明的，因此称为透明大页。
虽然透明大页使用起来非常方便、智能，但也有一定的代价：
进程内存占用可能远大所需：因为每次Page Fault 都尽量分配大页，即使此时应用程序只读写几KB
2）可能造成性能抖动：
- 在第 1 种进程内存占用可能远大所需的情况下，可能造成系统 free 内存更少，更容易触发内存回收；系统内存也更容易碎片化。
- khugepaged 线程合页时，容易触发页面规整甚至内存回收，该过程费时费力，容易造成 sys cpu 上升。
- mmap lock 本身是目前内核的一个性能瓶颈，应当尽量避免 write lock 的持有，但 THP 合页等操作都会持有写锁，且耗时较长（数据拷贝等），容易激化 mmap lock 锁竞争，影响性能。
因此 THP 还支持 madvise 模式，该模式需要应用程序指定使用大页的地址范围，内核只对指定的地址范围做 THP 相关的操作。这样可以更加针对性、更加细致地优化特定应用程序的性能，又不至于造成反向的负面影响。
可以通过 cmdline 参数和 sysfs 接口设置 THP 的模式：
- cmdline 参数：
transparent_hugepage=madvise
- sysfs 接口：
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
四、mmap_lock 锁
锁是内存管理中的一把知名的大锁，保护了诸如mm_struct 结构体成员、 vm_area_struct 结构体成员、页表释放等很多变量与操作。
mmap_lock 的实现是读写信号量， 当写锁被持有时，所有的其他读锁与写锁路径都会被阻塞。Linux 内核已经尽可能减少了写锁的持有场景以及时间，但不少场景还是不可避免的需要持有写锁，比如 mmap 以及 munmap 路径、mremap 路径和 THP 转换大页映射路径等场景。
应用程序应该避免频繁的调用会持有 mmap_lock 写锁的系统调用 (syscall)， 比如有时可以使用 madvise（MADV_DONTNEED）释放物理内存，该参数下，madvise 相比 munmap 只持有 mmap_lock 的读锁，并且只释放物理内存，不会释放 VMA 区域，因此可以再次访问对应的虚拟地址范围，而不需要重新调用 mmap 函数。
另外对于 MADV_DONTNEED，再次访问还是会触发 Page Fault 分配物理内存并填充页表，该操作也有一定的性能损耗。 如果想进一步减少这部分损耗，可以改为 MADV_FREE 参数，该参数也只会持有 mmap_lock 的读锁，区别在于不会立刻释放物理内存，会等到内存紧张时才进行释放，如果在释放之前再次被访问则无需再次分配内存，进而提高内存访问速度。
一般 mmap_lock 锁竞争激烈会导致很多 D 状态进程（TASK_UNINTERRUPTIBLE），这些 D 进程都是进程组的其他线程在等待写锁释放。因此可以打印出所有 D 进程的调用栈，看是否有大量 mmap_lock 的等待。
for i in `ps -aux | grep " D" | awk '{ print $2}'`; do echo $i; cat /proc/$i/stack; done
内核社区专门封装了 mmap_lock 相关函数，并在其中增加了 tracepoint，这样可以使用 bpftrace 等工具统计持有写锁的进程、调用栈等，方便排查问题，确定优化方向。
bpftrace -e 'tracepoint:mmap_lock:mmap_lock_start_locking /args->write == true/{ @[comm, kstack] = count();}'
五、跨numa内存访问
在 NUMA 架构下，CPU 访问本地 node 内存的速度要大于远端 node，因此应用程序应尽可能访问本地 node 上的内存。可以通过 numastat 工具查看 node 间的内存分配情况：
- 观察整机是否有很多 other_node 指标（远端内存访问）上涨：
watch -n 1 numastat -s
查看单个进程在各个node上的内存分配情况：
numastat -p <pid>
5.1 绑 node
可以通过 numactl 等工具把进程绑定在某个 node 以及对应的 CPU 上，这样该进程只会从该本地 node 上分配内存。 但这样做也有相应的弊端， 比如：该 node 剩余内存不够时，进程也无法从其他 node 上分配内存，只能期待内存回收后释放足够的内存，而如果进入直接内存回收会阻塞内存分配，就会有一定的性能损耗。
此外，进程组的线程数较多时，如果都绑定在一个 node 的 CPU 上，可能会造成 CPU 瓶颈，该损耗可能比远端 node 内存访问还大，比如 ngnix 进程与网卡就推荐绑定在不同的 node 上，这样虽然网卡收包时分配的内存在远端 node 上，但减少了本地 node 的 CPU 上的网卡中断，反而可以获得更好的性能提升。
5.2 numa balancing
内核还提供了 numa balancing 机制，可以通过 /proc/sys/kernel/numa_balancing 文件或者cmdline参数 numa_balancing=进行开启。
该机制可以动态的将进程访问的 page 从远端 node 迁移到本地 node 上，从而使进程可以尽可能的访问本地内存。但该机制实现也有相应的代价， 在 page 的迁移是通过 Page Fault 机制实现的，会有相应的性能损耗；另外如果迁移时找不到合适的目标 node，可能还会把进程迁移到正在访问的 page 的 node 的 CPU 上，这可能还会导致 cpu cache miss，从而对性能造成更大的影响。因此需要根据业务进程的具体行为，来决定是否开启numabalancing 功能。
