云主机云服务器

美国服务器本文对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 -Havailable: 2 nodes (0-1)node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23node 0 size: 15870 MBnode 0 free: 13780 MBnode 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31node 1 size: 16384 MBnode 1 free: 15542 MBnode distances:node 0 1 0: 10 21 1: 21 10
通过numastat查看NUMA的统计信息，包括内存分配的命中次数、未命中次数、本地分配次数和远端分配次数等。
[root@localhost ~]# numastat node0 node1numa_hit 2351854045 3021228076numa_miss 22736854 2976885numa_foreign 2976885 22736854interleave_hit 14144 14100local_node 2351844760 3021220020other_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 3975Node 0, zone DMA32 pages free 291250 managed 326897Node 0, zone Normal pages free 3232166 managed 3604347Node 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=1024mkdir -p /mnt/hugepagesmount -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 : tunables : slabdata fat_inode_cache 90 90 720 45 8 : tunables 0 0 0 : slabdata 2 2 0fat_cache 0 0 40 102 1 : tunables 0 0 0 : slabdata 0 0 0kvm_vcpu 0 0 16576 1 8 : tunables 0 0 0 : slabdata 0 0 0kvm_mmu_page_header 0 0 168 48 2 : tunables 0 0 0 : slabdata 0 0 0ext4_groupinfo_4k 4440 4440 136 30 1 : tunables 0 0 0 : slabdata 148 148 0ext4_inode_cache 63816 65100 1032 31 8 : tunables 0 0 0 : slabdata 2100 2100 0ext4_xattr 1012 1012 88 46 1 : tunables 0 0 0 : slabdata 22 22 0ext4_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 : tunables : slabdata kmalloc-8192 196 200 8192 4 8 : tunables 0 0 0 : slabdata 50 50 0kmalloc-4096 1214 1288 4096 8 8 : tunables 0 0 0 : slabdata 161 161 0kmalloc-2048 2861 2928 2048 16 8 : tunables 0 0 0 : slabdata 183 183 0kmalloc-1024 7993 8320 1024 32 8 : tunables 0 0 0 : slabdata 260 260 0kmalloc-512 6030 6144 512 32 4 : tunables 0 0 0 : slabdata 192 192 0kmalloc-256 7813 8576 256 32 2 : tunables 0 0 0 : slabdata 268 268 0kmalloc-192 15542 15750 192 42 2 : tunables 0 0 0 : slabdata 375 375 0kmalloc-128 16814 16896 128 32 1 : tunables 0 0 0 : slabdata 528 528 0kmalloc-96 17507 17934 96 42 1 : tunables 0 0 0 : slabdata 427 427 0kmalloc-64 48590 48704 64 64 1 : tunables 0 0 0 : slabdata 761 761 0kmalloc-32 7296 7296 32 128 1 : tunables 0 0 0 : slabdata 57 57 0kmalloc-16 14336 14336 16 256 1 : tunables 0 0 0 : slabdata 56 56 0kmalloc-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 vmvm.admin_reserve_kbytes = 8192vm.block_dump = 0vm.dirty_background_bytes = 0vm.dirty_background_ratio = 10vm.dirty_bytes = 0vm.dirty_expire_centisecs = 3000vm.dirty_ratio = 20vm.dirty_writeback_centisecs = 500vm.drop_caches = 1vm.extfrag_threshold = 500vm.hugepages_treat_as_movable = 0vm.hugetlb_shm_group = 0vm.laptop_mode = 0vm.legacy_va_layout = 0vm.lowmem_reserve_ratio = 256 256 32vm.max_map_count = 65530vm.memory_failure_early_kill = 0vm.memory_failure_recovery = 1vm.min_free_kbytes = 1024000vm.min_slab_ratio = 1vm.min_unmapped_ratio = 1vm.mmap_min_addr = 4096vm.nr_hugepages = 0vm.nr_hugepages_mempolicy = 0vm.nr_overcommit_hugepages = 0vm.nr_pdflush_threads = 0vm.numa_zonelist_order = defaultvm.oom_dump_tasks = 1vm.oom_kill_allocating_task = 0vm.overcommit_kbytes = 0vm.overcommit_memory = 0vm.overcommit_ratio = 50vm.page-cluster = 3vm.panic_on_oom = 0vm.percpu_pagelist_fraction = 0vm.stat_interval = 1vm.swappiness = 60vm.user_reserve_kbytes = 131072vm.vfs_cache_pressure = 100vm.zone_reclaim_mode = 0
vm.drop_caches
vm.drop_caches是最常用到的参数，因为Linux的Page cache（文件系统缓存）机制会导致大量的内存被用于文件系统缓存，包括数据缓存和元数据（dentry、inode）缓存。当内存不足时，我们通过该参数可以快速释放文件系统缓存：
To free pagecache: echo 1 > /proc/sys/vm/drop_cachesTo free reclaimable slab objects (includes dentries and inodes): echo 2 > /proc/sys/vm/drop_cachesTo 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

购买使用一诺网络美国服务器，可以极大降低初创企业、中小企业以及个人开发者等用户群体的整体IT使用成本，无需亲自搭建基础设施、简化了运维和管理的日常工作量，使用户能够更专注于自身的业务发展和创新。美国服务器低至49元/月，购买链接：https://www.enuoidc.com/vpszq.html?typeid=3