[轉]十問 Linux 虛擬內存管理 (glibc)

時間  2019-11-10
標籤 linux 虛擬 內存 管理 glibc 欄目 Linux 简体版
原文   原文鏈接

最近在作 MySQL 版本升級時（ 5.1->5.5 ） , 發現了 mysqld 疑似「內存泄露」現象，但經過 valgrind 等工具檢測後，並沒發現相似的問題。所以，須要深刻學習 Linux 的虛擬內存管理方面的內容來解釋這個現象。 Linux 的虛擬內存管理有幾個關鍵概念：1. 每一個進程有獨立的虛擬地址空間，進程訪問的虛擬地址並非真正的物理地址2. 虛擬地址可經過每一個進程上頁表與物理地址進行映射，得到真正物理地址3. 若是虛擬地址對應物理地址不在物理內存中，則產生缺頁中斷，真正分配物理地址，同時更新進程的頁表；若是此時物理內存已耗盡，則根據內存替換算法淘汰部分頁面至物理磁盤中。基於以上認識，這篇文章經過本人之前對虛擬內存管理的疑惑由淺入深整理了如下十個問題，並經過例子和系統命令嘗試進行解答。
1.Linux 虛擬地址空間如何分佈？ 32 位和 64 位有何不一樣？
2.malloc 是如何分配內存的？
3.malloc 分配多大的內存，就佔用多大的物理內存空間嗎？mysql

  1. 如何查看進程虛擬地址空間的使用狀況？
    5.free 的內存真的釋放了嗎（還給 OS ） ?linux

  2. 程序代碼中 malloc 的內存都有相應的 free ，就不會出現內存泄露了嗎？算法

  3. 既然堆內內存不能直接釋放，爲何不所有使用 mmap 來分配？sql

  4. 如何查看進程的缺頁中斷信息？編程

  5. 如何查看堆內內存的碎片狀況？數組

  6. 除了 glibc 的 malloc/free ，還有其餘第三方實現嗎？
    1.Linux 虛擬地址空間如何分佈？ 32 位和 64位有何不一樣？數據結構

Linux 使用虛擬地址空間，大大增長了進程的尋址空間，由低地址到高地址分別爲：
只讀段：該部分空間只能讀，不可寫，包括代碼段、 rodata 段（ C 常量字符串和 #define定義的常量）
數據段：保存全局變量、靜態變量的空間
堆 ：就是平時所說的動態內存， malloc/new 大部分都來源於此。其中堆頂的位置可經過函數 brk 和 sbrk 進行動態調整。
文件映射區域 ：如動態庫、共享內存等映射物理空間的內存，通常是 mmap 函數所分配的虛擬地址空間。
棧：用於維護函數調用的上下文空間，通常爲 8M ，可經過 ulimit –s 查看。
內核虛擬空間：用戶代碼不可見的內存區域，由內核管理。
下圖是 32 位系統典型的虛擬地址空間分佈（來自《深刻理解計算機系統》）。
32位系統典型虛擬地址空間分佈
32 位系統有 4G 的地址空間，其中 0x08048000~0xbfffffff 是用戶空間，0xc0000000~0xffffffff 是內核空間，包括內核代碼和數據、與進程相關的數據結構（如頁表、內核棧）等。另外， %esp 執行棧頂，往低地址方向變化； brk/sbrk 函數控制堆頂往高地址方向變化。可經過如下代碼驗證進程的地址空間分佈，其中 sbrk(0) 函數用於返回棧頂指針。
1: #include <stdlib.h>
2:
3: #include <stdio.h>
4:
5: #include <string.h>
6:
7: #include <unistd.h>
8:
9:
10: int global_num = 0;
11:
12: char global_str_arr [65536] = {'a'};
13:
14:
15: int main(int argc, char** argv)
16:
17: {
18:
19: char* heap_var = NULL;
20:
21: int local_var = 0;
22:
23:
24: printf("Address of function main 0x%lxn", main);
25:
26: printf("Address of global_num 0x%lxn", &global_num);
27:
28: printf("Address of global_str_arr 0x%lx ~ 0x%lxn", &global_str_arr[0], &global_str_arr[65535]);
29:
30: printf("Top of stack is 0x%lxn", &local_var);
31:
32: printf("Top of heap is 0x%lxn", sbrk(0));
33:
34: heap_var = malloc(sizeof(char) 127 1024);
35:
36: printf("Address of heap_var is 0x%lxn", heap_var);
37:
38: printf("Top of heap after malloc is 0x%lxn", sbrk(0));
39:
40: free(heap_var);
41:
42: heap_var = NULL;
43:
44: printf("Top of heap after free is 0x%lxn", sbrk(0));
45:
46: return 1;
47: }
32 位系統的結果以下，與上圖的劃分保持一致，而且棧頂指針在 mallloc 和 free 一個 127K的存儲空間時都發生了變化（增大和縮小）。
Address of function main 0x8048474併發

Address of global_num 0x8059904app

Address of global_str_arr 0x8049900 ~ 0x80598ffnosql

Top of stack is 0xbfd0886c

Top of heap is 0x805a000

Address of heap_var is 0x805a008

Top of heap after malloc is 0x809a000

Top of heap after free is 0x807b000
可是， 64 位系統結果怎樣呢？ 64 位系統是否擁有 2^64 的地址空間嗎？64 位系統運行結果以下：
Address of function main 0x400594

Address of global_num 0x610b90

Address of global_str_arr 0x600b80 ~ 0x610b7f

Top of stack is 0x7fff2e9e4994

Top of heap is 0x8f5000

Address of heap_var is 0x8f5010

Top of heap after malloc is 0x935000

Top of heap after free is 0x916000
從結果知，與上圖的分佈並不一致。而事實上， 64 位系統的虛擬地址空間劃分發生了改變：1. 地址空間大小不是 2^32 ，也不是 2^64 ，而通常是 2^48 。由於並不須要 2^64 這麼大的尋址空間，過大空間只會致使資源的浪費。 64 位 Linux 通常使用 48 位來表示虛擬地址空間， 40 位表示物理地址，這可經過 /proc/cpuinfo 來查看address sizes : 40 bits physical, 48 bits virtual2. 其中， 0x0000000000000000~0x00007fffffffffff 表示用戶空間，0xFFFF800000000000~ 0xFFFFFFFFFFFFFFFF 表示內核空間，共提供 256TB(2^48) 的尋址空間。這兩個區間的特色是，第 47 位與 48~63 位相同，若這些位爲 0 表示用戶空間，不然表示內核空間。3. 用戶空間由低地址到高地址仍然是隻讀段、數據段、堆、文件映射區域和棧
2.malloc 是如何分配內存的？
malloc 是 glibc 中內存分配函數，也是最經常使用的動態內存分配函數，其內存必須經過 free進行釋放，不然致使內存泄露。關於 malloc 得到虛存空間的實現，與 glibc 的版本有關，但大致邏輯是：1. 若分配內存小於 128k ，調用 sbrk() ，將堆頂指針向高地址移動，得到新的虛存空間。2. 若分配內存大於 128k ，調用 mmap() ，在文件映射區域中分配匿名虛存空間。3. 這裏討論的是簡單狀況，若是涉及併發可能會複雜一些，不過先不討論。其中 sbrk 就是修改棧頂指針位置，而 mmap 可用於生成文件的映射以及匿名頁面的內存，這裏指的是匿名頁面。而這個 128k ，是 glibc 的默認配置，可經過函數 mallopt 來設置，可經過如下例子說明。

include <stdlib.h>

include <stdio.h>

include <string.h>

include <unistd.h>

include <sys/mman.h>

include <malloc.h>

void print_info(

char*      var_name,

    char*      var_ptr,

    size_t     size_in_kb

)

{

printf("Address of %s(%luk) 0x%lx,  now heap top is 0x%lx\n",

                    var_name, size_in_kb, var_ptr, sbrk(0));

}

int main(int argc, char** argv)

{

char *heap_var1, *heap_var2, *heap_var3 ;

    char *mmap_var1, *mmap_var2, *mmap_var3 ;

    char *maybe_mmap_var;
printf("Orginal heap top is 0x%lx\n", sbrk(0));
heap_var1 = malloc(32*1024);

    print_info("heap_var1", heap_var1, 32);

    heap_var2 = malloc(64*1024);

    print_info("heap_var2", heap_var2, 64);

    heap_var3 = malloc(127*1024);

    print_info("heap_var3", heap_var3, 127);
printf("\n");

    maybe_mmap_var = malloc(128*1024);

    print_info("maybe_mmap_var", maybe_mmap_var, 128);
//mmap

    mmap_var1 = malloc(128*1024);

    print_info("mmap_var1", mmap_var1, 128);
// set M_MMAP_THRESHOLD to 64k

    mallopt(M_MMAP_THRESHOLD, 64*1024);

    printf("set M_MMAP_THRESHOLD to 64k\n");
mmap_var2 = malloc(64*1024);

    print_info("mmap_var2", mmap_var2, 64);

    mmap_var3 = malloc(127*1024);

    print_info("mmap_var3", mmap_var3, 127);
return 1;

}
這個例子很簡單，經過 malloc 申請多個不一樣大小的動態內存，同時經過接口 print_info 打印變量大小和地址等相關信息，其中 sbrk(0) 可返回堆頂指針位置。另外，粗體部分是將 MMAP分配的臨界點由 128k 轉爲 64k ，再打印變量地址的不一樣。下面是 Linux 64 位機器的執行結果（後文全部例子都是經過 64 位機器上的測試結果）。Orginal heap top is 0x17da000Address of heap_var1(32k) 0x17da010, now heap top is 0x1803000Address of heap_var2(64k) 0x17e2020, now heap top is 0x1803000Address of heap_var3(127k) 0x17f2030, now heap top is 0x1832000Address of maybe_mmap_var(128k) 0x1811c40, now heap top is 0x1832000Address of mmap_var1(128k) 0x7f4a0b1f2010, now heap top is 0x1832000set M_MMAP_THRESHOLD to 64kAddress of mmap_var2(64k) 0x7f4a0b1e1010, now heap top is 0x1832000Address of mmap_var3(127k) 0x7f4a0b1c1010, now heap top is 0x1832000由以上結果知：1. 申請 128k 之內的內存（ heap_var1/2/3 ，其內存地址比較小，而且地址 + 長度總小於堆頂 (sbrk(0)) ，即在堆內分配，虛擬地址比較小。2. 第一次申請內存的 heap_var1 與分配前的堆頂地址相鄰很近（只差 16 字節），事實上，每次分配的內存地址前 16 字節（ 64 位系統， 32 位是 8 字節）是記錄該內存塊的控制信息（用於 free ）。3. 並非每次 malloc 都會致使堆頂的增大，例如分配 heap_var2 堆頂沒有變化，事實上每次 malloc 堆頂至少增大 128k ，若是堆內有足夠剩餘空間，堆頂不會發生變化。4. 當分配大小大於 128k ，使用 mmap 得到地址空間，地址通常比較大（靠近棧區間），如 mmap_var15. 但當堆頂有足夠剩餘空間，仍優先使用堆內空間，而不使用 mmap ，如maybe_mmap_var 雖然分配 128k ，但還是堆內分配。6. 可經過函數 mallopt(M_MMAP_THRESHOLD, 64*1024) 修改使用 mmap 的臨界值爲64k ，後續大於 64k 的分配就會使用 mmap ，如 mmap_var2/3.
3.malloc 分配多大的內存，就佔用多大的物理內存空間嗎？
咱們知道， malloc 分配的的內存是虛擬地址空間，而虛擬地址空間和物理地址空間使用進程頁表進行映射，那麼分配了空間就是佔用物理內存空間了嗎？首先，進程使用多少內存可經過 ps aux 命令 查看，其中關鍵的兩信息（第5、六列）爲：1. VSZ ， virtual memory size ，表示進程總共使用的虛擬地址空間大小，包括進程地址空間的代碼段、數據段、堆、文件映射區域、棧、內核空間等全部虛擬地址使用的總和，單位是 K2. RSS ， resident set size ，表示進程實際使用的物理內存空間， RSS 總小於 VSZ 。可經過一個例子說明這個問題：

include <stdlib.h>

include <stdio.h>

include <string.h>

include <unistd.h>

include <sys/mman.h>

include <malloc.h>

char ps_cmd[1024];

void print_info(

char*      var_name,

    char*      var_ptr,

    size_t     size_in_kb

)

{

printf("Address of %s(%luk) 0x%lx,  now heap top is 0x%lx\n",

                    var_name, size_in_kb, var_ptr, sbrk(0));

    system(ps_cmd);

}

int main(int argc, char** argv)

{

char *non_set_var, *set_1k_var, *set_5k_var, *set_7k_var;

    pid_t pid;
pid = getpid();

    sprintf(ps_cmd, "ps aux | grep %lu | grep -v grep", pid);
non_set_var = malloc(32*1024);

    print_info("non_set_var", non_set_var, 32);
set_1k_var = malloc(64*1024);

    memset(set_1k_var, 0, 1024);

    print_info("set_1k_var", set_1k_var, 64);
set_5k_var = malloc(127*1024);

    memset(set_5k_var, 0, 5*1024);

    print_info("set_5k_var", set_5k_var, 127);
set_7k_var = malloc(64*1024);

    memset(set_1k_var, 0, 7*1024);

    print_info("set_7k_var", set_7k_var, 64);
return 1;

}
該代碼擴展了上一個例子 print_info 能力，處理打印變量信息，同時經過 ps aux 命令得到當前進程的 VSZ 和 RSS 值。而且程序 malloc 一塊內存後，會 memset 內存的若干 k 內容。執行結果爲
Address of non_set_var(32k) 0x502010, now heap top is 0x52b000

mysql 12183 0.0 0.0 2692 452 pts/3 S+ 20:29 0:00 ./test_vsz

Address of set_1k_var(64k) 0x50a020, now heap top is 0x52b000

mysql 12183 0.0 0.0 2692 456 pts/3 S+ 20:29 0:00 ./test_vsz

Address of set_5k_var(127k) 0x51a030, now heap top is 0x55a000

mysql 12183 0.0 0.0 2880 464 pts/3 S+ 20:29 0:00 ./test_vsz

Address of set_7k_var(64k) 0x539c40, now heap top is 0x55a000

mysql 12183 0.0 0.0 2880 472 pts/3 S+ 20:29 0:00 ./test_vsz
由以上結果知：1. VSZ 並非每次 malloc 後都增加，是與上一節說的堆頂沒發生變化有關，由於可重用堆頂內剩餘的空間，這樣的 malloc 是很輕量快速的。2. 但若是 VSZ 發生變化，基本與分配內存量至關，由於 VSZ 是計算虛擬地址空間總大小。3. RSS 的增量不多，是由於 malloc 分配的內存並不就立刻分配實際存儲空間，只有第一次使用，如第一次 memset 後纔會分配。4. 因爲每一個物理內存頁面大小是 4k ，無論 memset 其中的 1k 仍是 5k 、 7k ，實際佔用物理內存老是 4k 的倍數。因此 RSS 的增量老是 4k 的倍數。5. 所以，不是 malloc 後就立刻佔用實際內存，而是第一次使用時發現虛存對應的物理頁面未分配，產生缺頁中斷，才真正分配物理頁面，同時更新進程頁面的映射關係。這也是Linux 虛擬內存管理的核心概念之一。

  1. 如何查看進程虛擬地址空間的使用狀況？
    進程地址空間被分爲了代碼段、數據段、堆、文件映射區域、棧等區域，那怎麼查詢這些虛擬地址空間的使用狀況呢？Linux 提供了 pmap 命令來查看這些信息，一般使用 pmap -d $pid （高版本可提供 pmap -x $pid ）查詢，以下所示：

mysql@ TLOG_590_591:~/vin/test_memory> pmap -d 17867

17867: test_mmap

START SIZE RSS DIRTY PERM OFFSET DEVICE MAPPING

00400000 8K 4K 0K r-xp 00000000 08:01 /home/mysql/vin/test_memory/test_mmap

00501000 68K 8K 8K rw-p 00001000 08:01 /home/mysql/vin/test_memory/test_mmap

00512000 76K 0K 0K rw-p 00512000 00:00 [heap]

0053e000 256K 0K 0K rw-p 0053e000 00:00 [anon]

2b3428f97000 108K 92K 0K r-xp 00000000 08:01 /lib64/ld-2.4.so

2b3428fb2000 8K 8K 8K rw-p 2b3428fb2000 00:00 [anon]

2b3428fc1000 4K 4K 4K rw-p 2b3428fc1000 00:00 [anon]

2b34290b1000 8K 8K 8K rw-p 0001a000 08:01 /lib64/ld-2.4.so

2b34290b3000 1240K 248K 0K r-xp 00000000 08:01 /lib64/libc-2.4.so

2b34291e9000 1024K 0K 0K ---p 00136000 08:01 /lib64/libc-2.4.so

2b34292e9000 12K 12K 12K r--p 00136000 08:01 /lib64/libc-2.4.so

2b34292ec000 8K 8K 8K rw-p 00139000 08:01 /lib64/libc-2.4.so

2b34292ee000 1048K 36K 36K rw-p 2b34292ee000 00:00 [anon]

7fff81afe000 84K 12K 12K rw-p 7fff81afe000 00:00 [stack]

ffffffffff600000 8192K 0K 0K ---p 00000000 00:00 [vdso]

Total: 12144K 440K 96K
從這個結果能夠看到進程虛擬地址空間的使用狀況，包括起始地址、大小、實際使用內存、髒頁大小、權限、偏移、設備和映射文件等。 pmap 命令就是基於下面兩文件內容進行解析的：
/proc/$pid/maps

/proc/$pid/smaps
而且對於上述每一個內存塊區間，內核會使用一個 vm_area_struct 結構來維護，同時經過頁面創建與物理內存的映射關係，以下圖所示
。
5.free 的內存真的釋放了嗎（還給 OS ） ?
前面全部例子都有一個很嚴重的問題，就是分配的內存都沒有釋放，即致使內存泄露。原則上全部 malloc/new 分配的內存，都需 free/delete 來釋放。可是， free 了的內存真的釋放了嗎？要說清楚這個問題，可經過下面例子來講明。
(1) 初始狀態：如圖 (1) 所示，系統已分配 ABCD 四塊內存，其中 ABD 在堆內分配， C 使用 mmap 分配。爲簡單起見，圖中忽略瞭如共享庫等文件映射區域的地址空間。
(2) E=malloc(100k) ：分配 100k 內存，小於 128k ，從堆內分配，堆內剩餘空間不足，擴展堆頂 (brk) 指針。
(3) free(A) ：釋放 A 的內存，在 glibc 中，僅僅是標記爲可用，造成一個內存空洞 ( 碎片 )，並無真正釋放。若是此時須要分配 40k 之內的空間，可重用此空間，剩餘空間造成新的小碎片。
(4) free(C) ：C 空間大於 128K ，使用 mmap 分配，若是釋放 C ，會調用 munmap 系統調用來釋放，並會真正釋放該空間，還給 OS ，如圖 (4) 所示。

(5) free(D) ：與釋放 A 相似，釋放 D 一樣會致使一個空洞，得到空閒空間，但並不會還給OS 。此時，空閒總空間爲 100K ，但因爲虛擬地址不連續，沒法合併，空閒空間沒法知足大於 60k 的分配請求。
(6) free(E) ：釋放 E ，因爲與 D 連續，二者將進行合併，獲得 160k 連續空閒空間。同時E 是最靠近堆頂的空間， glibc 的 free 實現中，只要堆頂附近釋放總空間（包括合併的空間）超過 128k ，即會調用 sbrk(-SIZE) 來回溯堆頂指針，將原堆頂空間還給 OS ，如圖(6) 所示。而堆內的空閒空間仍是不會歸還 OS 的。

因而可知：1. malloc 使用 mmap 分配的內存 ( 大於 128k) ， free 會調用 munmap 系統調用立刻還給 OS ，實現真正釋放。2. 堆內的內存，只有釋放堆頂的空間，同時堆頂總連續空閒空間大於 128k 才使用 sbrk(-SIZE) 回收內存，真正歸還 OS 。3. 堆內的空閒空間，是不會歸還給 OS 的。

  1. 程序代碼中 malloc 的內存都有相應的 free，就不會出現內存泄露了嗎？
    狹義上的內存泄露是指 malloc 的內存，沒有 free ，致使內存浪費，直到程序結束。而廣義上的內存泄露就是進程使用內存量不斷增長，或大大超出系統原設計的上限。上一節說到， free 了的內存並不會立刻歸還 OS ，而且堆內的空洞（碎片）更是很難真正釋放，除非空洞成爲了新的堆頂。因此，如上一例子狀況 (5) ，釋放了 40k 和 60k 兩片內存，但若是此時須要申請大於 60k （如 70k ），沒有可用碎片，必須向 OS 申請，實際使用內存仍然增大。所以，隨着系統頻繁地 malloc 和 free ，尤爲對於小塊內存，堆內將產生愈來愈多不可用的碎片，致使「內存泄露」。而這種「泄露」現象使用 valgrind 是沒法檢測出來的。下圖是 MySQL 存在大量分區表時的內存使用狀況 (RSS 和 VSZ) ，疑似「內存泄露」。

所以，當咱們寫程序時，不能徹底依賴 glibc 的 malloc 和 free 的實現。更好方式是創建屬於進程的內存池，即一次分配 (malloc) 大塊內存，小內存從內存池中得到，當進程結束或該塊內存不可用時，一次釋放 (free) ，可大大減小碎片的產生。

  1. 既然堆內內存不能直接釋放，爲何不所有使用 mmap 來分配？
    因爲堆內碎片不能直接釋放，而問題 5 中說到 mmap 分配的內存能夠會經過 munmap 進行 free ，實現真正釋放。既然堆內碎片不能直接釋放，致使疑似「內存泄露」問題，爲何malloc 不所有使用 mmap 來實現呢？而僅僅對於大於 128k 的大塊內存才使用 mmap ？其實，進程向 OS 申請和釋放地址空間的接口 sbrk/mmap/munmap 都是系統調用，頻繁調用系統調用都比較消耗系統資源的。而且， mmap 申請的內存被 munmap 後，從新申請會產生更多的缺頁中斷。例如使用 mmap 分配 1M 空間，第一次調用產生了大量缺頁中斷(1M/4K 次 ) ，當 munmap 後再次分配 1M 空間，會再次產生大量缺頁中斷。缺頁中斷是內核行爲，會致使內核態 CPU 消耗較大。另外，若是使用 mmap 分配小內存，會致使地址空間的分片更多，內核的管理負擔更大，見《 高性能編程須要注意大內存申請》。而堆是一個連續空間，而且堆內碎片因爲沒有歸還 OS ，若是可重用碎片，再次訪問該內存極可能不需產生任何系統調用和缺頁中斷，這將大大下降 CPU 的消耗。所以， glibc 的 malloc 實現中，充分考慮了 sbrk 和 mmap 行爲上的差別及優缺點，默認分配大塊內存 (128k) 才使用 mmap 得到地址空間，也可經過mallopt(M_MMAP_THRESHOLD, <SIZE>) 來修改這個臨界值。

  2. 如何查看進程的缺頁中斷信息？
    可經過如下命令查看缺頁中斷信息

ps -o majflt,minflt -C <program_name>

ps -o majflt,minflt -p <pid>
其中， majflt 表明 major fault ，指大錯誤， minflt 表明 minor fault ，指小錯誤。這兩個數值表示一個進程自啓動以來所發生的缺頁中斷的次數。其中 majflt 與 minflt 的不一樣是，majflt 表示須要讀寫磁盤，多是內存對應頁面在磁盤中須要 load 到物理內存中，也多是此時物理內存不足，須要淘汰部分物理頁面至磁盤中。
例如，下面是 mysqld 的一個例子。
mysql@ TLOG_590_591:~> ps -o majflt,minflt -C mysqld

MAJFLT MINFLT

144856 15296294
若是進程的內核態 CPU 使用過多，其中一個緣由就多是單位時間的缺頁中斷次數多個，可經過以上命令來查看。若是 MAJFLT 過大，極可能是內存不足。若是 MINFLT 過大，極可能是頻繁分配 / 釋放大塊內存 (128k) ， malloc 使用 mmap 來分配。對於這種狀況，可經過 mallopt(M_MMAP_THRESHOLD, <SIZE>) 增大臨界值，或程序實現內存池。

  1. 如何查看堆內內存的碎片狀況？

  2. 提供瞭如下結構和接口來查看堆內內存和 mmap 的使用狀況。

struct mallinfo {

int arena; / non-mmapped space allocated from system /

int ordblks; / number of free chunks /

int smblks; / number of fastbin blocks /

int hblks; / number of mmapped regions /

int hblkhd; / space in mmapped regions /

int usmblks; / maximum total allocated space /

int fsmblks; / space available in freed fastbin blocks /

int uordblks; / total allocated space /

int fordblks; / total free space /

int keepcost; / top-most, releasable (via malloc_trim) space /

};

/ 返回 heap(main_arena) 的內存使用狀況，以 mallinfo 結構返回 /

struct mallinfo mallinfo();

/ 將 heap 和 mmap 的使用狀況輸出到 stderr /

void malloc_stats();
可經過如下例子來驗證 mallinfo 和 malloc_stats 輸出結果。

include <stdlib.h>

include <stdio.h>

include <string.h>

include <unistd.h>

include <sys/mman.h>

include <malloc.h>

size_t heap_malloc_total, heap_free_total,

mmap_total, mmap_count;

void print_info()

{

struct mallinfo mi = mallinfo();
printf("count by itself:\n");

    printf("\theap_malloc_total=%lu heap_free_total=%lu heap_in_use=%lu\n\

tmmap_total=%lu mmap_count=%lun",

heap_malloc_total*1024, heap_free_total*1024, heap_malloc_total*1024 - heap_free_total*1024,

            mmap_total*1024, mmap_count);
printf("count by mallinfo:\n");

    printf("\theap_malloc_total=%lu heap_free_total=%lu heap_in_use=%lu\n\

tmmap_total=%lu mmap_count=%lun",

mi.arena, mi.fordblks, mi.uordblks,

            mi.hblkhd, mi.hblks);
printf("from malloc_stats:\n");

    malloc_stats();

}

define ARRAY_SIZE 200

int main(int argc, char** argv)

{

char** ptr_arr[ARRAY_SIZE];

    int i;

    for( i = 0; i < ARRAY_SIZE; i++) {

            ptr_arr[i] = malloc(i * 1024);
if ( i < 128)

                    heap_malloc_total += i;

            else {

                    mmap_total += i;

                    mmap_count++;

            }

    }

    print_info();
for( i = 0; i < ARRAY_SIZE; i++) {

            if ( i % 2 == 0)

                    continue;
free(ptr_arr[i]);
if ( i < 128)

                    heap_free_total += i;

            else {

                    mmap_total -= i;

                    mmap_count--;

            }

    }

    printf("\nafter free\n");

    print_info();
return 1;

}
該例子第一個循環爲指針數組每一個成員分配索引位置 (KB) 大小的內存塊，並經過 128 爲分界分別對 heap 和 mmap 內存分配狀況進行計數；第二個循環是 free 索引下標爲奇數的項，同時更新計數狀況。經過程序的計數與 mallinfo/malloc_stats 接口獲得結果進行對比，並經過print_info 打印到終端。下面是一個執行結果：
count by itself:

heap_malloc_total=8323072 heap_free_total=0 heap_in_use=8323072

    mmap_total=12054528 mmap_count=72

count by mallinfo:

heap_malloc_total=8327168 heap_free_total=2032 heap_in_use=8325136

    mmap_total=12238848 mmap_count=72

from malloc_stats:

Arena 0:

system bytes = 8327168

in use bytes = 8325136

Total (incl. mmap):

system bytes = 20566016

in use bytes = 20563984

max mmap regions = 72

max mmap bytes = 12238848

after free

count by itself:

heap_malloc_total=8323072 heap_free_total=4194304 heap_in_use=4128768

    mmap_total=6008832 mmap_count=36

count by mallinfo:

heap_malloc_total=8327168 heap_free_total=4197360 heap_in_use=4129808

    mmap_total=6119424 mmap_count=36

from malloc_stats:

Arena 0:

system bytes = 8327168

in use bytes = 4129808

Total (incl. mmap):

system bytes = 14446592

in use bytes = 10249232

max mmap regions = 72

max mmap bytes = 12238848
由上可知，程序統計和 mallinfo 獲得的信息基本吻合，其中 heap_free_total 表示堆內已釋放的內存碎片總和。若是想知道堆內片究竟有多碎 ，可經過 mallinfo 結構中的 fsmblks 、 smblks 、 ordblks值獲得，這些值表示不一樣大小區間的碎片總個數，這些區間分別是 0~80 字節， 80~512 字節，512~128k 。若是 fsmblks 、 smblks 的值過大，那碎片問題可能比較嚴重了。不過， mallinfo 結構有一個很致命的問題，就是其成員定義所有都是 int ，在 64 位環境中，其結構中的 uordblks/fordblks/arena/usmblks 很容易就會致使溢出，應該是歷史遺留問題，使用時要注意！

  1. 除了 glibc 的 malloc/free ，還有其餘第三方實現嗎？
    其實，不少人開始詬病 glibc 內存管理的實現，就是在高併發性能低下和內存碎片化問題都比較嚴重，所以，陸續出現一些第三方工具來替換 glibc 的實現，最著名的當屬 google 的tcmalloc 和 facebook 的 jemalloc 。網上有不少資源，可搜索之，這裏就不詳述了。

總結
基於以上認識，最後發現 MySQL 的疑似「內存泄露」問題一方面是 MySQL 5.5 分區表使用更多的內存，另外一方面跟內存碎片有關，這也是 TMySQL 一個優化方向。然而，以上主要介紹了 glibc 虛擬內存管理主要內容，事實上，在併發狀況下， glibc 的虛存管理會更加複雜，碎片狀況也可能更嚴重，這將在另外一篇再作介紹。推薦另外一篇文章《深刻剖析glibc內存管理實現及潛在問題》
參考：
《深刻理解計算機系統》第 10 章
http://www.kernel.org/doc/Doc...
https://en.wikipedia.org/wiki...
https://www.ibm.com/developer...
http://www.kerneltravel.net/j...
http://blog.csdn.net/baidufor...
http://www.nosqlnotes.net/arc...

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程