Linux内存管理机制简单分析

本文对Linux内存管理机制做一个简单的分析，试图让你快速理解Linux一些内存管理的概念并有效的利用一些管理方法。

NUMA

Linux 2.6开始支持NUMA（ Non-Uniform Memory Access ）内存管理模式。在多个CPU的系统中，内存按CPU划分为不同的Node，每个CPU挂一个Node，其访问本地Node比访问其他CPU上的Node速度要快很多。
 通过numactl -H查看NUMA硬件信息，可以看到2个node的大小和对应的CPU核，以及CPU访问node的distances。如下所示CPU访问远端node的distances是本地node的2倍多。

[root@localhost ~]# numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 15870 MB
node 0 free: 13780 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 16384 MB
node 1 free: 15542 MB
node distances:
node  0  1
  0:  10  21
  1:  21  10

通过numastat查看NUMA的统计信息，包括内存分配的命中次数、未命中次数、本地分配次数和远端分配次数等。

[root@localhost ~]# numastat
                          node0          node1
numa_hit              2351854045      3021228076
numa_miss              22736854        2976885
numa_foreign            2976885        22736854
interleave_hit            14144          14100
local_node            2351844760      3021220020
other_node              22746139        2984941

Zone

Node下面划分为一个或多个Zone，为啥要有Zone，两个原因：1.DMA设备能够访问的内存范围有限（ISA设备只能访问16MB）；2.x86-32bit系统地址空间有限（32位最多只能4GB），为了使用更大内存，需要使用HIGHMEM机制。

ZONE_DMA

地址段最低的一块内存区域，用于ISA(Industry Standard Architecture)设备DMA访问。在x86架构下，该Zone大小限制为16MB。

ZONE_DMA32

该Zone用于支持32-bits地址总线的DMA设备，只在64-bits系统里才有效。

ZONE_NORMAL

该Zone的内存被内核直接映射为线性地址并可以直接使用。在X86-32架构下，该Zone对应的地址范围为16MB~896MB。在X86-64架构下，DMA和DMA32之外的内存全部在NORMAL的Zone里管理。

ZONE_HIGHMEM

该Zone只在32位系统才有，通过建立临时页表的方式映射超过896MB的内存空间。即在需要访问的时候建立地址空间和内存的映射关系，在访问结束后拆掉映射关系释放地址空间，该地址空间可以用于其他HIGHMEM的内存映射。

通过/proc/zoneinfo可以查看Zone相关的信息。如下所示X86-64系统上两个Node，Node0上有DMA、DMA32和Normal三个Zone，Node1上只有一个Normal Zone。

[root@localhost ~]# cat /proc/zoneinfo |grep -E “zone| free|managed”
Node 0, zone      DMA
  pages free    3700
        managed  3975
Node 0, zone    DMA32
  pages free    291250
        managed  326897
Node 0, zone  Normal
  pages free    3232166
        managed  3604347
Node 1, zone  Normal
  pages free    3980110
        managed  4128056

Page

Page是Linux底层内存管理的基本单位，大小为4KB。一个Page映射为一段连续的物理内存，内存的分配和释放都要以Page为单位进行。进程虚拟地址到物理地址的映射也是通过Page Table页表进行，页表的每一项记录一个Page的虚拟地址对应的物理地址。

TLB

内存访问时需要查找地址对应的Page结构，这个数据记录在页表里。所有对内存地址的访问都要先查询页表，因此页表的访问次数是频率最高的。为了提高对页表的访问速度，引入了TLB（Translation Lookaside Buffer）机制，将访问较多页表缓存在CPU的cache里。因此CPU的性能统计里很重要的一项就是L1/L2 cache的TLB miss统计项。在内存较大的系统里，如256GB内存全量的页表项有256GB/4KB=67108864条，每个条目占用16字节的话，需要1GB，显然是CPU cache无法全量缓存的。这时候如果访问的内存范围较广很容易出现TLB miss导致访问延时的增加。

Hugepages

为了降低TLB miss的概率，Linux引入了Hugepages机制，可以设定Page大小为2MB或者1GB。2MB的Hugepages机制下，同样256GB内存需要的页表项降低为256GB/2MB=131072，仅需要2MB。因此Hugepages的页表可以全量缓存在CPU cache中。
 通过sysctl -w vm.nr_hugepages=1024可以设置hugepages的个数为1024，总大小为4GB。需要注意是，设置huagepages会从系统申请连续2MB的内存块并进行保留（不能用于正常内存申请），如果系统运行一段时间导致内存碎片较多时，再申请hugepages会失败。
 如下所示为hugepages的设置和mount方法，mount之后应用程序需要在mount路径下通过mmap进行文件映射来使用这些hugepages。

sysctl -w vm.nr_hugepages=1024
mkdir -p /mnt/hugepages
mount -t hugetlbfs hugetlbfs /mnt/hugepages

Buddy System

Linux Buddy System是为了解决以Page为单位的内存分配导致外内存碎片问题：即系统缺少连续的Page页导致需要连续Page页的内存申请无法得到满足。原理很简单，将不同个数的连续Pages组合成Block进行分配，Block按2的幂次方个Pages划分为11个Block链表，分别对应1，2，4，8，16，32，64，128，256，512和1024个连续的Pages。调用Buddy System进行内存分配时，根据申请的大小找最合适的Block。
 如下所示为各个Zone上的Buddy System基本信息，后面11列为11个Block链表里可用的Block个数。

[root@localhost ~]# cat /proc/buddyinfo
Node 0, zone      DMA      0      0      1      0      1      1      1      0      0      1      3
Node 0, zone    DMA32    102    79    179    229    230    166    251    168    107    78    169
Node 0, zone  Normal  1328    900  1985  1920  2261  1388    798    972    539    324  2578
Node 1, zone  Normal    466  1476  2133  7715  6026  4737  2883  1532    778    490  2760

Slab

Buddy System的内存都是大块申请，但是大多数应用需要的内存都很小，比如常见的几百个Bytes的数据结构，如果也申请一个Page，将会非常浪费。为了满足小而不规则的内存分配需求，Linux设计了Slab分配器。原理简单说就是为特定的数据结构建立memcache，从Buddy System里申请Pages，将每个Page按数据结构的大小划分为多个Objects，使用者从memcache里申请数据结构时分配一个Object。
 如下所示为Linux查看slab信息的方法：

[root@localhost ~]# cat /proc/slabinfo
slabinfo – version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
fat_inode_cache      90    90    720  45    8 : tunables    0    0    0 : slabdata      2      2      0
fat_cache              0      0    40  102    1 : tunables    0    0    0 : slabdata      0      0      0
kvm_vcpu              0      0  16576    1    8 : tunables    0    0    0 : slabdata      0      0      0
kvm_mmu_page_header      0      0    168  48    2 : tunables    0    0    0 : slabdata      0      0      0
ext4_groupinfo_4k  4440  4440    136  30    1 : tunables    0    0    0 : slabdata    148    148      0
ext4_inode_cache  63816  65100  1032  31    8 : tunables    0    0    0 : slabdata  2100  2100      0
ext4_xattr          1012  1012    88  46    1 : tunables    0    0    0 : slabdata    22    22      0
ext4_free_data    16896  17600    64  64    1 : tunables    0    0    0 : slabdata    275    275      0

通常我们都是通过slabtop命令查看排序后的slab信息：

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                 
352014 352014 100%    0.10K  9026  39    36104K buffer_head
 93492  93435  99%    0.19K  2226  42    17808K dentry
 65100  63816  98%    1.01K  2100  31    67200K ext4_inode_cache
 48128  47638  98%    0.06K    752  64  3008K kmalloc-64
 47090  43684  92%    0.05K    554  85  2216K shared_policy_node
 44892  44892 100%    0.11K  1247  36  4988K sysfs_dir_cache
 43624  43177  98%    0.07K    779  56  3116K Acpi-ParseExt
 43146  42842  99%    0.04K    423  102  1692K ext4_extent_status

kmalloc

和glibc的malloc()一样，内核也提供kmalloc()用于分配任意大小的内存空间。同样，如果放任应用程序随意从Page里申请任意大小的内存也会导致Page内���内存碎片化。为了解决内部碎片问题，Linux使用Slab机制来实现kmalloc内存分配。原理和Buddy System类似，即创建2的幂次方的Slab池用于kmalloc根据大小适配最佳的Slab进行分配。
 如下所示为用于kmalloc分配的Slabs：

[root@localhost ~]# cat /proc/slabinfo
slabinfo – version: 2.1
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
kmalloc-8192        196    200  8192    4    8 : tunables    0    0    0 : slabdata    50    50      0
kmalloc-4096        1214  1288  4096    8    8 : tunables    0    0    0 : slabdata    161    161      0
kmalloc-2048        2861  2928  2048  16    8 : tunables    0    0    0 : slabdata    183    183      0
kmalloc-1024        7993  8320  1024  32    8 : tunables    0    0    0 : slabdata    260    260      0
kmalloc-512        6030  6144    512  32    4 : tunables    0    0    0 : slabdata    192    192      0
kmalloc-256        7813  8576    256  32    2 : tunables    0    0    0 : slabdata    268    268      0
kmalloc-192        15542  15750    192  42    2 : tunables    0    0    0 : slabdata    375    375      0
kmalloc-128        16814  16896    128  32    1 : tunables    0    0    0 : slabdata    528    528      0
kmalloc-96        17507  17934    96  42    1 : tunables    0    0    0 : slabdata    427    427      0
kmalloc-64        48590  48704    64  64    1 : tunables    0    0    0 : slabdata    761    761      0
kmalloc-32          7296  7296    32  128    1 : tunables    0    0    0 : slabdata    57    57      0
kmalloc-16        14336  14336    16  256    1 : tunables    0    0    0 : slabdata    56    56      0
kmalloc-8          21504  21504      8  512    1 : tunables    0    0    0 : slabdata    42    42      0

内核参数

Linux提供了一些内存管理相关的内核参数，在/proc/sys/vm目录下可以查看或者通过sysctl -a |grep vm查看：

[root@localhost vm]# sysctl -a |grep vm
vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.drop_caches = 1
vm.extfrag_threshold = 500
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256  256 32
vm.max_map_count = 65530
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 1024000
vm.min_slab_ratio = 1
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 4096
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.nr_pdflush_threads = 0
vm.numa_zonelist_order = default
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
vm.swappiness = 60
vm.user_reserve_kbytes = 131072
vm.vfs_cache_pressure = 100
vm.zone_reclaim_mode = 0

vm.drop_caches

vm.drop_caches是最常用到的参数，因为Linux的Page cache（文件系统缓存）机制会导致大量的内存被用于文件系统缓存，包括数据缓存和元数据（dentry、inode）缓存。当内存不足时，我们通过该参数可以快速释放文件系统缓存：

To free pagecache:
    echo 1 > /proc/sys/vm/drop_caches
To free reclaimable slab objects (includes dentries and inodes):
    echo 2 > /proc/sys/vm/drop_caches
To free slab objects and pagecache:
    echo 3 > /proc/sys/vm/drop_caches

vm.min_free_kbytes

vm.min_free_kbytes用于决定内存低于多少时启动内存回收机制（包括上面提到的文件系统缓存和下面会提到的可回收的Slab），该值默认值较小，在内存较多的系统设置为一个较大的值（如1GB）可以在内存还不会太少时自动触发内存回收。但也不能设置太大，导致频繁应用程序经常被OOM killed。

sysctl -w vm.min_free_kbytes=1024000

vm.min_slab_ratio

vm.min_slab_ratio用于决定Slab池里可回收的Slab空间在该Zone里的占比达到多少时进行回收，默认是5%。但经过笔者试验，当内存充足时根本不会触发Slab回收，也只有在内存水位线达到上面min_free_kbytes时才会触发Slab回收。该值最小可以设置为1%：

sysctl -w vm.min_slab_ratio=1

总结

以上简单描述了Linux内存管理机制和几个常用的内存管理内核参数。

参考资料

Understanding The Linux Kernel 3rd Edition
[Linux Physical Memory Description]](http://www.ilinuxkernel.com/files/Linux_Physical_Memory_Description.pdf)

本文永久更新链接地址：https://www.linuxidc.com/Linux/2018-05/152624.htm