Linux内存管理机制简析

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)