分布式存储开发：Curve中的内存管理

前言

Curve 实践过程当中遇到过几回内存相关的问题，与操做系统内存管理相关的是如下两次：html

chunkserver上内存没法释放
mds出现内存缓慢增加的现象

内存问题在开发阶段大多很难发现，测试阶段大压力稳定性测试(持续跑7*24小时以上)、异常测试每每比较容易出问题，固然这还须要咱们在测试阶段足够仔细，除了关注io相关指标外，还要关注服务端内存/CPU/网卡等资源使用状况以及采集的metric是否符合预期。好比上述问题mds 内存缓慢增加，若是只关注io是否正常，在测试阶段是没法发现的。内存问题出现后定位也不容易，尤为在软件规模较大的状况下。node

本文主要是从开发者的角度来谈 Curve 中的内存管理，不会过分强调内存管理理论，目的是把咱们在软件开发过程当中对 Linux 内存管理的认知、内存问题分析的一些方法分享给你们。本文会从如下几个方面展开：linux

内存布局。结合 Curve 软件说明内存布局。
内存分配策略。说明内存分配器的必要性，以及须要解决的问题和具备的特色，而后经过举例说明其中一个内存分配器的内存管理方法。
Curve 的内存管理。介绍当前 Curve 软件内存分配器的选择及缘由。

内存布局

在说内存管理以前，首先简要介绍下内存布局相关知识。git

软件在运行时须要占用必定量的内存用来存放一些数据，但进程并不直接与存放数据的物理内存打交道，而是直接操做虚拟内存。物理内存是真实的存在，就是内存条；虚拟内存为进程隐藏了物理内存这一律念，为进程提供了简洁易用的接口和更加复杂的功能。本文说的内存管理是指虚拟内存管理。为何须要抽象一层虚拟内存？虚拟内存和物理内存是如何映射管理的？物理寻址是怎么的？这些虚拟内存更下层的问题不在本文讨论范围。github

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 表示地址空间随机化已开启，数值一、2的区别在于随机化的关键部分不一样；0表示关闭。session
接下来 0x559f0e2b9000 0x559f0eb9f000 0x559f0ebc1000 三个地址起始对应的文件都是curve-mds ，可是对该文件的拥有不一样的权限，各字母表明的权限r-读 w-写 x-可执行 p-私有 s-共享。curve-mds 是elf类型文件，从内容的角度看，它包含代码段、数据段、BSS段等；从装载到内存角度看，操做系统不关心各段所包含的内容，只关心跟装载相关的问题，主要是权限，因此操做系统会把相同权限的段合并在一块儿去加载，就是咱们这里看到的以代码段为表明的权限为可读可执行的段、以只读数据为表明的权限为只读的段、以数据段和 BSS 段为表明的权限为可读可写的段。多线程
再往下 0x559f1110a000 开始，对应上图的运行时堆，运行时动态分配的内存会在这上面进行。咱们发现也是在.bss段的结束位置进行了随机偏移。app
接着 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 管理着。由一、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 ）个。

举个多线程的例子来看下这种状况下的空间分配：

// 共有三个线程
// 主线程：分配一次 4k 空间
// 线程1: 分配 100 次 4k 空间
// 线程2: 分配 100 次 4k 空间
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
#include <sys/types.h>
 
void* threadFunc(void* id) {
		std::vector<char *> malloclist;
		for (int i = 0; i < 100; i++) {
		  malloclist.emplace_back((char*) malloc(1024 * 4));
		}
 
		sleep(300); // 这里等待是为查看内存分布
}
int main() {
    pthread_t t1,t2;
		int id1 = 1;
		int id2 = 2;
    void* s;
    int ret;
    char* addr;
 
    addr = (char*) malloc(4 * 1024);
    pthread_create(&t1, NULL, threadFunc, (void *) &id1);
    pthread_create(&t2, NULL, threadFunc, (void *) &id2);
 
		pthread_join(t1, NULL);
		pthread_join(t2, NULL);
    return 0;
}

咱们用 pmap 查看下该程序的内存分布状况：

741545:   ./memory_test
         Address Perm   Offset Device    Inode   Size  Rss Pss  Mapping
    56127705a000 r-xp 00000000  08:02 62259273      4    4   4  memory_test
    56127725a000 r--p 00000000  08:02 62259273      4    4   4  memory_test
    56127725b000 rw-p 00001000  08:02 62259273      4    4   4  memory_test
    5612784b9000 rw-p 00000000  00:00        0    132    8   8  [heap]
    **7f0df0000000 rw-p 00000000  00:00        0    404  404 404  
    7f0df0065000 ---p 00000000  00:00        0  65132    0   0  
    7f0df8000000 rw-p 00000000  00:00        0    404  404 404  
    7f0df8065000 ---p 00000000  00:00        0  65132    0   0**  
    7f0dff467000 ---p 00000000  00:00        0      4    0   0  
    7f0dff468000 rw-p 00000000  00:00        0   8192    8   8  
    7f0dffc68000 ---p 00000000  00:00        0      4    0   0  
    7f0dffc69000 rw-p 00000000  00:00        0   8192    8   8  
    7f0e00469000 r-xp 00000000  08:02 50856517   1620 1052   9   libc-2.24.so
    7f0e005fe000 ---p 00195000  08:02 50856517   2048    0   0   libc-2.24.so
    7f0e007fe000 r--p 00195000  08:02 50856517     16   16  16   libc-2.24.so
    7f0e00802000 rw-p 00199000  08:02 50856517      8    8   8   libc-2.24.so
    7f0e00804000 rw-p 00000000  00:00        0     16   12  12   
    7f0e00808000 r-xp 00000000  08:02 50856539     96   96   1   libpthread-2.24.so
    7f0e00820000 ---p 00018000  08:02 50856539   2044    0   0   libpthread-2.24.so
    7f0e00a1f000 r--p 00017000  08:02 50856539      4    4   4   libpthread-2.24.so
    7f0e00a20000 rw-p 00018000  08:02 50856539      4    4   4   libpthread-2.24.so
    7f0e00a21000 rw-p 00000000  00:00        0     16    4   4   
    7f0e00a25000 r-xp 00000000  08:02 50856513    140  140   1   ld-2.24.so
    7f0e00c31000 rw-p 00000000  00:00        0     16   16  16   
    7f0e00c48000 r--p 00023000  08:02 50856513      4    4   4   ld-2.24.so
    7f0e00c49000 rw-p 00024000  08:02 50856513      4    4   4   ld-2.24.so
    7f0e00c4a000 rw-p 00000000  00:00        0      4    4   4   
    7ffe340be000 rw-p 00000000  00:00        0    132   12  12   [stack]
    7ffe3415c000 r--p 00000000  00:00        0      8    0   0   [vvar]
    7ffe3415e000 r-xp 00000000  00:00        0      8    4   0   [vdso]
ffffffffff600000 r-xp 00000000  00:00        0      4    0   0   [vsyscall]
                                               ====== ==== === 
                                               153800 2224 943

关注上面加粗的部分，红色区域加起来是 65536K，其中有 404K 是 rw-p （可读可写）权限，65132K 是 —-p （不可读写）权限；黄色区域相似。两个线程分配的时 ptmalloc 分别给了动态分区，而且每次申请 64M 内存，再从这 64M 中切分出一部分给应用程序。

这里还有一个有意思的现象：咱们用strace -f -e "brk, mmap, munmap" -p {pid}去跟踪程序查看下 malloc 中的系统调用：

mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f624a169000
strace: Process 774601 attached
[pid 774018] mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f6249968000
[pid 774601] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f6241968000
[pid 774601] munmap(0x7f6241968000, 40468480strace: Process 774602 attached
) = 0
[pid 774601] munmap(0x7f6248000000, 26640384) = 0
[pid 774602] mmap(NULL, 134217728, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x7f623c000000
[pid 774602] munmap(0x7f6240000000, 67108864) = 0

这里主线程 [774018] 要求分配了 8M+4k 空间；线程1 [774601] 先 mmap 了 128M 空间，再分归还了 0x7f6241968000 为起始地址的 40468480 字节和 0x7f6248000000为起始地址的 26640384 字节，那剩余的部分是 0x7F6244000000 ~ 0x7F6248000000。先申请再归仍是为了让分配的这部份内存的起止地址是字节对齐的。

Curve 的内存管理

Curve 中选择了两种分配器：ptmalloc和jemalloc。其中 MDS 使用默认的 ptmalloc，Chunkserver 和 Client 端使用 jemalloc。

本文开头提到的两个问题在这里进行说明。首先是MDS内存缓慢增加，现象是天天增加 3G。这个问题分析的过程以下：

首先是使用pmap查看内存分布。咱们用 pmap 查看内存缓慢增加的 curve-mds 内存分配状况，发如今 Memory Mapping Region 存在着大量分配的 64M 内存，且观察一段时间后都不释放还在一直分配。从这里怀疑存在内存泄露。
而后查看应用上请求的压力状况。查看MDS 上相关的业务 metric，发现 MDS 上的压力都很小，一些控制面 rpc 的 iops 在几百左右，不该该是业务压力较大致使的。
接下来查看 curve-mds 部分 64M 内存上的数据。使用gdb -p {pid} attach跟踪线程，dump meemory mem.bin {addr1} {addr2}获取指定地址段的内存，而后查看这部份内存内容，基本肯定几个怀疑点。
根据这几个点去排查代码，看是否有内存泄露。

Chunkserver 端不是开始就使用 jemalloc 的，最初也是用的默认的 ptmalloc。换成 jemalloc 是本文开始提到的 Chunkserver 在测试过程当中出现内存没法释放的问题，这个问题的现象是：chunkserver的内存在 2 个小时内增加很快，一共增加了 50G 左右，但后面并未释放。这个问题分析的过程以下：

首先分析内存中数据来源。这一点跟 MDS 不一样，MDS 上都是控制面的请求以及一些元数据的缓存。而Chunkserver 上的内存增加通常来自两个地方：一是用户发送的请求，二是 copyset 的 leader 和 follower 之间同步数据。这两个都会涉及到 brpc 模块。

brpc 的内存管理有两个模块 IOBuf 和 ResourcePool。IOBuf 中的空间通常用于存放用户数据，ResourcePool 管理 socket、bthread_id 等对象，管理的内存对象单位是 64K 。
查看对应模块的一些趋势指标。观察这两个模块的metric，发现 IOBuf 和 ResourcePool 这段时间内占用的内存都有相同的增加趋势。

IOBuf 后面将占用的内存归还给 ptmalloc， ResourcePool 中管理的内存不会归还给 ptmalloc 而是本身管理。

从这个现象咱们怀疑 IOBuf 归还给 ptmalloc 的内存 ptmalloc 没法释放。
分析验证。结合第二节的内存分配策略，若是堆顶的空间一直被占用，那堆顶向下的空间也是没法被释放的。仍然可使用 pmap 查看当前堆上内存的大小以及内存的权限（是否有不少 —-p 权限的内存）来肯定猜测。所以后面 Chunkserver 使用了 jemalloc。这里能够看到在多线程状况下，若是一部份内存被应用长期持有，使用 ptmalloc 也许就会遇到内存没法释放的问题。

这里对 MDS 和 Chunkserver 出现的两个问题进行了总结，一方面想说明 Curve 选择不一样内存分配器的缘由。对于一个从 0 到 1 的项目，代码开发之初选择内存分配器不是一个特别重要的事情，若是有比较多的开发和解决相似内存问题的经验，开始作出评估是好的；但若是没有，能够先选择一个，出现问题或者到须要优化内存性能的时候再去分析。另一方面但愿能够给遇到相似内存问题的小伙伴一些定位的思路。

做者：李小翠，网易数帆存储团队Curve项目攻城狮。

若有理解和描述上有疏漏或者错误的地方，欢迎共同交流；参考已经在参考文献中注明，但仍有可能有疏漏的地方，有任何侵权或者不明确的地方，欢迎指出，一定及时更正或者删除；文章供于学习交流，转载注明出处

参考文献

[1]ptmalloc,tcmalloc,jemalloc对比分析

[2]十问linux虚拟内存管理(glibc)

[3]Go语言使用cgo时的内存管理笔记

[3] 深刻理解计算机系统 [美] 兰德尔 E.布莱恩特（Randal E.·Bryant）著，龚奕利，贺莲译

相关连接

Curv项目介绍

网易数帆存储负责人亲述：我眼中的 Curve 与 Ceph

Curve开源技术直播（每周五19:00）

Curve的roadmap