13518219792
本篇文章给大家分享的是有关怎么分析Curve中的内存管理，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。
我们提供的服务有：网站设计、网站制作、微信公众号开发、网站优化、网站认证、庐山ssl等。为上千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的庐山网站制作公司
Curve 实践过程中遇到过几次内存相关的问题，与操作系统内存管理相关的是以下两次：
chunkserver上内存无法释放
mds出现内存缓慢增长的现象
内存问题在开发阶段大多很难发现，测试阶段大压力稳定性测试(持续跑7*24小时以上)、异常测试往往比较容易出问题，当然这还需要我们在测试阶段足够仔细，除了关注io相关指标外，还要关注服务端内存/CPU/网卡等资源使用情况以及采集的metric是否符合预期。比如上述问题mds 内存缓慢增长，如果只关注io是否正常，在测试阶段是无法发现的。内存问题出现后定位也不容易，尤其在软件规模较大的情况下。
下面主要是从开发者的角度来谈 Curve 中的内存管理，不会过度强调内存管理理论，目的是把我们在软件开发过程中对 Linux 内存管理的认知、内存问题分析的一些方法分享给大家。本文会从以下几个方面展开：
内存布局。结合 Curve 软件说明内存布局。
内存分配策略。说明内存分配器的必要性，以及需要解决的问题和具有的特点，然后通过举例说明其中一个内存分配器的内存管理方法。
Curve 的内存管理。介绍当前 Curve 软件内存分配器的选择及原因。
在说内存管理之前，首先简要介绍下内存布局相关知识。
软件在运行时需要占用一定量的内存用来存放一些数据，但进程并不直接与存放数据的物理内存打交道，而是直接操作虚拟内存。物理内存是真实的存在，就是内存条；虚拟内存为进程隐藏了物理内存这一概念，为进程提供了简洁易用的接口和更加复杂的功能。本文说的内存管理是指虚拟内存管理。为什么需要抽象一层虚拟内存？虚拟内存和物理内存是如何映射管理的？物理寻址是怎么的？这些虚拟内存更下层的问题不在本文讨论范围。
Linux 为每个进程维护了一个单独的虚拟地址空间，包括两个部分进程虚拟存储器（用户空间）和内核虚拟存储器（内核空间），小编主要讨论进程可操作的用户空间，形式如下图。
现在我们使用pmap查看运行中的 curve-mds 虚拟空间的分布。pmap用于查看进程的内存映像信息，该命令读取的是/proc/[pid]/maps中的信息。
// pmap -X {进程id} 查看进程内存分布
sudo pmap -X 2804620
// pmap 获取的 curve-mds 内存分布有很多项
Address Perm Offset Device Inode Size Rss Pss Referenced Anonymous ShmemPmdMapped Shared_Hugetlb Private_Hugetlb Swap SwapPss Locked Mapping
// 为了方便展示这里把从 Pss 后面的数值删除了, 中间部分地址做了省略
2804620: /usr/bin/curve-mds -confPath=/etc/curve/mds.conf -mdsAddr=127.0.0.1:6666 -log_dir=/data/log/curve/mds -graceful_quit_on_sigterm=true -stderrthreshold=3
Address Perm Offset Device Inode Size Rss Pss Mapping
c000000000 rw-p 00000000 00:00 0 65536 1852 1852
559f0e2b9000 r-xp 00000000 41:42 37763836 9112 6296 6296 curve-mds
559f0eb9f000 r--p 008e5000 41:42 37763836 136 136 136 curve-mds
559f0ebc1000 rw-p 00907000 41:42 37763836 4 4 4 curve-mds
559f0ebc2000 rw-p 00000000 00:00 0 10040 4244 4244
559f1110a000 rw-p 00000000 00:00 0 2912 2596 2596 [heap]
7f6124000000 rw-p 00000000 00:00 0 156 156 156
7f6124027000 ---p 00000000 00:00 0 65380 0 0
7f612b7ff000 ---p 00000000 00:00 0 4 0 0
7f612b800000 rw-p 00000000 00:00 0 8192 8 8
7f612c000000 rw-p 00000000 00:00 0 132 4 4
7f612c021000 ---p 00000000 00:00 0 65404 0 0
.....
7f6188cff000 ---p 0026c000 41:42 37750237 2044 0 0
7f61895b7000 r-xp 00000000 41:42 50201214 96 96 0 libpthread-2.24.so
7f61895cf000 ---p 00018000 41:42 50201214 2044 0 0 libpthread-2.24.so
7f61897ce000 r--p 00017000 41:42 50201214 4 4 4 libpthread-2.24.so
7f61897cf000 rw-p 00018000 41:42 50201214 4 4 4 libpthread-2.24.so
7f61897d0000 rw-p 00000000 00:00 0 16 4 4
7f61897d4000 r-xp 00000000 41:42 50200647 16 16 0 libuuid.so.1.3.0
7f61897d8000 ---p 00004000 41:42 50200647 2044 0 0 libuuid.so.1.3.0
7f61899d7000 r--p 00003000 41:42 50200647 4 4 4 libuuid.so.1.3.0
7f61899d8000 rw-p 00004000 41:42 50200647 4 4 4 libuuid.so.1.3.0
7f61899d9000 r-xp 00000000 41:42 37617895 9672 8904 8904 libetcdclient.so
7f618a34b000 ---p 00972000 41:42 37617895 2048 0 0 libetcdclient.so
7f618a54b000 r--p 00972000 41:42 37617895 6556 5664 5664 libetcdclient.so
7f618abb2000 rw-p 00fd9000 41:42 37617895 292 252 252 libetcdclient.so
7f618abfb000 rw-p 00000000 00:00 0 140 60 60
7f618ac1e000 r-xp 00000000 41:42 50201195 140 136 0 ld-2.24.so
7f618ac4a000 rw-p 00000000 00:00 0 1964 1236 1236
7f618ae41000 r--p 00023000 41:42 50201195 4 4 4 ld-2.24.so
7f618ae42000 rw-p 00024000 41:42 50201195 4 4 4 ld-2.24.so
7f618ae43000 rw-p 00000000 00:00 0 4 4 4
7fffffd19000 rw-p 00000000 00:00 0 132 24 24 [stack]
7fffffdec000 r--p 00000000 00:00 0 8 0 0 [vvar]
7fffffdee000 r-xp 00000000 00:00 0 8 4 0 [vdso]
ffffffffff600000 r-xp 00000000 00:00 0 4 0 0 [vsyscall]
======= ===== =====
1709344 42800 37113上面输出中进程实际占用的空间是从 0x559f0e2b9000 开始，不是内存分布图上画的 0x40000000。这是因为地址空间分布随机化（ASLR），它的作用是随机生成进程地址空间（例如栈、库或者堆）的关键部分的起始地址，目的是增强系统安全性、避免恶意程序对已知地址攻击。Linux 中/proc/sys/kernel/randomize_va_space的值为 1 或 2 表示地址空间随机化已开启，数值1、2的区别在于随机化的关键部分不同；0表示关闭。
接下来 0x559f0e2b9000 0x559f0eb9f000 0x559f0ebc1000 三个地址起始对应的文件都是curve-mds ，但是对该文件的拥有不同的权限，各字母代表的权限r-读 w-写 x-可执行 p-私有 s-共享。curve-mds 是elf类型文件，从内容的角度看，它包含代码段、数据段、BSS段等；从装载到内存角度看，操作系统不关心各段所包含的内容，只关心跟装载相关的问题，主要是权限，所以操作系统会把相同权限的段合并在一起去加载，就是我们这里看到的以代码段为代表的权限为可读可执行的段、以只读数据为代表的权限为只读的段、以数据段和 BSS 段为代表的权限为可读可写的段。
再往下 0x559f1110a000 开始，对应上图的运行时堆，运行时动态分配的内存会在这上面进行 。我们发现也是在.bss段的结束位置进行了随机偏移。
接着 0x7f6124000000 开始，对应的是上图 mmap 内存映射区域，这一区域包含动态库、用户申请的大片内存等。到这里我们可以看到Heap和Memory Mapping Region都可以用于程序中使用malloc动态分配的内存，在下一节内存分配策略中会有展开，也是本文关注重点。
接着 0x7fffffd19000 开始是栈空间，一般有数兆字节。
最后 vvar、vdso、vsyscall 区域是为了实现虚拟函数调用以加速部分系统调用，使得程序可以不进入内核态1直接调用系统调用。这里不具体展开。
我们平时使用malloc分配出来的内存是在Heap和Memory Mapping Region这两个区域。mallloc 实际上由两个系统调用完成：brk和mmap
brk 分配的区域对应堆 heap
mmap 分配的区域对应 Memory Mapping Region
如果让每个开发者在软件开发时都直接使用系统调 brk 和 mmap 用去分配释放内存，那开发效率将会变得很低，而且也很容易出错。一般来说我们在开发中都会直接使用内存管理库，当前主流的内存管理器有三种：ptmalloc``tcmalloc``jemalloc, 都提供malloc, free接口，glibc 默认使用ptmalloc。这些库的作用是管理它通过系统调用获得的内存区域，一般来说一个优秀的通用内存分配器应该具有以下特征：
额外的空间损耗量尽量少。比如应用程序只需要5k内存，结果分配器给他分配了10k，会造成空间的浪费。
分配的速度尽可能快。
尽量避免内存碎片。下面我们结合图来直观的感受下内存碎片。
通用性、兼容性、可移植性、易调试。
我们通过下面一幅图直观说明下 glibc 默认的内存管理器 ptmalloc 在单线程情况下堆内存的回收和分配：
malloc(30k)通过系统调用 brk 扩展堆顶的方式分配内存。
malloc(20k)通过系统调用 brk 继续扩展堆顶。
malloc(200k)默认情况下请求内存大于 128K （由M_MMAP_THRESHOLD确定，默认大小为128K，可以调整），就利用系统调用 mmap分配内存。
free(30k)这部分空间并没有归还给系统，而是 ptmalloc 管理着。由1、2两步的 malloc 可以看出，我们分配空间的时候调用 brk 进行堆顶扩展，那归还空间给系统是相反操作即收缩堆顶。这里由于第二步 malloc(20k) 的空间并未释放，所以此时堆顶无法收缩。这部分空间是可以被再分配的，比如此时 malloc(10k)，那可以从这里分配 10k 空间，而不需要通过 brk 去申请。考虑这样一种情况，堆顶的空间一直被占用，堆顶向下的空间有部分被应用程序释放但由于空间不够没有再被使用，就会形成内存碎片。
free(20k)这部分空间应用程序释放后，ptmalloc 会把刚才的 20k 和 30k 的区域合并，如果堆顶空闲超过M_TRIM_THREASHOLD，会把这块区域收缩归还给操作系统。
free(200k)mmap分配出来的空间会直接归还给系统。
那对于多线程程序，ptmalloc 又是怎么区分配的？多线程情况下需要处理各线程间的竞争，如果还是按照之前的方式，小于HEAP_MAX_SIZE（ 64 位系统默认大小为 64M ）的空间使用 brk 扩展堆顶， 大于HEAP_MAX_SIZE的空间使用 mmap 申请，那对于线程数量较多的程序，如果每个线程上存在比较频繁的内存分配操作，竞争会很激烈。ptmalloc 的方法是使用多个分配区域，包含两种类型分配区：主分配区 和 动态分配区。
主分配区：会在Heap和Memory Mapping Region这两个区域分配内存
动态分配区：在Memory Mapping Region区域分配内存，在 64 位系统中默认每次申请的大小位。Main 线程和先执行 malloc 的线程使用不同的动态分配区，动态分配区的数量一旦增加就不会减少了。动态分配区的数量对于 32 位系统最多是 ( 2 number of cores + 1 ) 个，对于 64 位系统最多是（ 8 number of cores + 1 ）个。
举个多线程的例子来看下这种情况下的空间分配：
