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 2984941Zone
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 4128056Page
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/hugepagesBuddy 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 2760Slab
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 : tunables : slabdata
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_statuskmalloc
和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 : tunables : slabdata
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 = 0vm.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_cachesvm.min_free_kbytes
vm.min_free_kbytes用于决定内存低于多少时启动内存回收机制（包括上面提到的文件系统缓存和下面会提到的可回收的Slab），该值默认值较小，在内存较多的系统设置为一个较大的值（如1GB）可以在内存还不会太少时自动触发内存回收。但也不能设置太大，导致频繁应用程序经常被OOM killed。
sysctl -w vm.min_free_kbytes=1024000vm.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)