189 8069 5689

怎么分析Curve中的内存管理

本篇文章给大家分享的是有关怎么分析Curve中的内存管理，小编觉得挺实用的，因此分享给大家学习，希望大家阅读完这篇文章后可以有所收获，话不多说，跟着小编一起来看看吧。

我们提供的服务有：网站设计、网站制作、微信公众号开发、网站优化、网站认证、庐山ssl等。为上千家企事业单位解决了网站和推广的问题。提供周到的售前咨询和贴心的售后服务，是有科学管理、有技术的庐山网站制作公司

前言

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

  1. chunkserver上内存无法释放

  2. mds出现内存缓慢增长的现象

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

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

  • 内存布局。结合 Curve 软件说明内存布局。

  • 内存分配策略。说明内存分配器的必要性，以及需要解决的问题和具有的特点，然后通过举例说明其中一个内存分配器的内存管理方法。

  • Curve 的内存管理。介绍当前 Curve 软件内存分配器的选择及原因。

内存布局

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

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

Linux 为每个进程维护了一个单独的虚拟地址空间，包括两个部分进程虚拟存储器（用户空间）和内核虚拟存储器（内核空间），小编主要讨论进程可操作的用户空间，形式如下图。

怎么分析Curve中的内存管理

现在我们使用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

  1. 上面输出中进程实际占用的空间是从 0x559f0e2b9000 开始，不是内存分布图上画的 0x40000000。这是因为地址空间分布随机化（ASLR），它的作用是随机生成进程地址空间（例如栈、库或者堆）的关键部分的起始地址，目的是增强系统安全性、避免恶意程序对已知地址攻击。Linux 中/proc/sys/kernel/randomize_va_space的值为 1 或 2 表示地址空间随机化已开启，数值1、2的区别在于随机化的关键部分不同；0表示关闭。

  2. 接下来 0x559f0e2b9000 0x559f0eb9f000 0x559f0ebc1000 三个地址起始对应的文件都是curve-mds ，但是对该文件的拥有不同的权限，各字母代表的权限r-读 w-写 x-可执行 p-私有 s-共享。curve-mds 是elf类型文件，从内容的角度看，它包含代码段、数据段、BSS段等；从装载到内存角度看，操作系统不关心各段所包含的内容，只关心跟装载相关的问题，主要是权限，所以操作系统会把相同权限的段合并在一起去加载，就是我们这里看到的以代码段为代表的权限为可读可执行的段、以只读数据为代表的权限为只读的段、以数据段和 BSS 段为代表的权限为可读可写的段。

  3. 再往下 0x559f1110a000 开始，对应上图的运行时堆，运行时动态分配的内存会在这上面进行 。我们发现也是在.bss段的结束位置进行了随机偏移。

  4. 接着 0x7f6124000000 开始，对应的是上图 mmap 内存映射区域，这一区域包含动态库、用户申请的大片内存等。到这里我们可以看到Heap和Memory Mapping Region都可以用于程序中使用malloc动态分配的内存，在下一节内存分配策略中会有展开，也是本文关注重点。

  5. 接着 0x7fffffd19000 开始是栈空间，一般有数兆字节。

  6. 最后 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。这些库的作用是管理它通过系统调用获得的内存区域，一般来说一个优秀的通用内存分配器应该具有以下特征：

  1. 额外的空间损耗量尽量少。比如应用程序只需要5k内存，结果分配器给他分配了10k，会造成空间的浪费。

  2. 分配的速度尽可能快。

  3. 尽量避免内存碎片。下面我们结合图来直观的感受下内存碎片。

  4. 通用性、兼容性、可移植性、易调试。

我们通过下面一幅图直观说明下 glibc 默认的内存管理器 ptmalloc 在单线程情况下堆内存的回收和分配：

怎么分析Curve中的内存管理

  1. malloc(30k)通过系统调用 brk 扩展堆顶的方式分配内存。

  2. malloc(20k)通过系统调用 brk 继续扩展堆顶。

  3. malloc(200k)默认情况下请求内存大于 128K （由M_MMAP_THRESHOLD确定，默认大小为128K，可以调整），就利用系统调用 mmap分配内存。

  4. free(30k)这部分空间并没有归还给系统，而是 ptmalloc 管理着。由1、2两步的 malloc 可以看出，我们分配空间的时候调用 brk 进行堆顶扩展，那归还空间给系统是相反操作即收缩堆顶。这里由于第二步 malloc(20k) 的空间并未释放，所以此时堆顶无法收缩。这部分空间是可以被再分配的，比如此时 malloc(10k)，那可以从这里分配 10k 空间，而不需要通过 brk 去申请。考虑这样一种情况，堆顶的空间一直被占用，堆顶向下的空间有部分被应用程序释放但由于空间不够没有再被使用，就会形成内存碎片。

  5. free(20k)这部分空间应用程序释放后，ptmalloc 会把刚才的 20k 和 30k 的区域合并，如果堆顶空闲超过M_TRIM_THREASHOLD，会把这块区域收缩归还给操作系统。

  6. 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 
#include 
#include 
#include 
#include 
 
void* threadFunc(void* id) {
		std::vector 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。这个问题分析的过程如下：

  1. 首先是使用pmap查看内存分布。我们用 pmap 查看内存缓慢增长的 curve-mds 内存分配情况，发现在 Memory Mapping Region 存在着大量分配的 64M 内存，且观察一段时间后都不释放还在一直分配。从这里怀疑存在内存泄露。

  2. 然后查看应用上请求的压力情况。查看MDS 上相关的业务 metric，发现 MDS 上的压力都很小，一些控制面 rpc 的 iops 在几百左右，不应该是业务压力较大导致的。

  3. 接下来查看 curve-mds 部分 64M 内存上的数据。使用gdb -p {pid} attach跟踪线程，dump meemory mem.bin {addr1} {addr2}获取指定地址段的内存，然后查看这部分内存内容，基本确定几个怀疑点。

  4. 根据这几个点去排查代码，看是否有内存泄露。

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

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

    brpc 的内存管理有两个模块 IOBuf 和 ResourcePool。IOBuf 中的空间一般用于存放用户数据，ResourcePool 管理 socket、bthread_id 等对象，管理的内存对象单位是 64K 。

  2. 查看对应模块的一些趋势指标。观察这两个模块的metric，发现 IOBuf 和 ResourcePool 这段时间内占用的内存都有相同的增长趋势。

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

    从这个现象我们怀疑 IOBuf 归还给 ptmalloc 的内存 ptmalloc 无法释放。

  3. 分析验证。结合第二节的内存分配策略，如果堆顶的空间一直被占用，那堆顶向下的空间也是无法被释放的。仍然可以使用 pmap 查看当前堆上内存的大小以及内存的权限（是否有很多 —-p 权限的内存）来确定猜想。因此后面 Chunkserver 使用了 jemalloc。这里可以看到在多线程情况下，如果一部分内存被应用长期持有，使用 ptmalloc 也许就会遇到内存无法释放的问题。

以上就是怎么分析Curve中的内存管理，小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注创新互联行业资讯频道。


文章名称：怎么分析Curve中的内存管理
标题链接：http://jkwzsj.com/article/ijgpos.html

其他资讯