0引言

對于嵌入式設(shè)備來說，用戶態(tài)內(nèi)存管理是一項(xiàng)基礎(chǔ)功能，目前主流的用戶態(tài)內(nèi)存管理庫有g(shù)libc、uclibc、tcmalloc、jemalloc等。

本文基于glibc2.17版本進(jìn)行分析，圍繞glibc內(nèi)存分配原理、內(nèi)存站崗問題形成原因展開討論，并對glibc緩存大量內(nèi)存(高達(dá)幾十個(gè) G甚至上百 G)且不釋放的問題給出一種解決方案。

筆者遇到的問題是基于glibc進(jìn)行內(nèi)存管理的64 位Linux系統(tǒng)。具體現(xiàn)象如下：設(shè)備32G物理內(nèi)存，在大規(guī)格打流情況下，某用戶進(jìn)程占用的物理內(nèi)存暴漲至20G左右。

在停止打流后，觀察到業(yè)務(wù)模塊已經(jīng)釋放了絕大部分內(nèi)存，但是進(jìn)程占用的物理內(nèi)存依然達(dá)到16G左右，此后內(nèi)存狀況一直維持該狀態(tài)，導(dǎo)致系統(tǒng)內(nèi)存緊張，若疊加上其他業(yè)務(wù)則出現(xiàn)了OOM的現(xiàn)象，已排除該進(jìn)程內(nèi)存泄露的可能性。

1Glibc內(nèi)存分配基本原理

Glibc使用了ptmalloc的內(nèi)存管理方式，本文在描述時(shí)均使用glibc來稱呼。Glibc申請內(nèi)存時(shí)是從分配區(qū)申請的，分為主分配區(qū)和非主分配區(qū)，分配區(qū)都有鎖，在分配內(nèi)存前需要先獲取鎖，然后再去申請內(nèi)存。

一般進(jìn)程都是多線程的，當(dāng)多個(gè)線程同時(shí)需要申請內(nèi)存時(shí)，如果只有一個(gè)分配區(qū)，那么效率太低。

glibc為了支持多線程的內(nèi)存申請釋放，會(huì)在多個(gè)線程同時(shí)需要申請內(nèi)存時(shí)根據(jù)cpu核數(shù)分配一定數(shù)量的分配區(qū)，將分配區(qū)分配給線程。如果線程數(shù)量較多，則會(huì)出現(xiàn)多個(gè)線程爭用一個(gè)分配區(qū)的的情況，這里不展開。

內(nèi)存申請基本原理：當(dāng)用戶調(diào)用malloc申請內(nèi)存時(shí)，glibc會(huì)查看是否已經(jīng)緩存了內(nèi)存，如果有緩存則會(huì)優(yōu)先使用緩存內(nèi)存，返回一塊符合用戶請求大小的內(nèi)存塊。

如果沒有緩存或者緩存不足則會(huì)去向操作系統(tǒng)申請內(nèi)存(可通過brk、mmap申請內(nèi)存)，然后切一塊內(nèi)存給用戶，如圖1所示。

圖 1

內(nèi)存釋放基本原理：當(dāng)業(yè)務(wù)模塊使用完畢后調(diào)用free釋放內(nèi)存時(shí)，glibc會(huì)檢查該內(nèi)存塊虛擬地址上下內(nèi)存塊的使用狀態(tài)(fast bin除外)。若其上一塊內(nèi)存空閑，則與上一塊內(nèi)存進(jìn)行合并。若下一塊內(nèi)存空閑，則與下一塊內(nèi)存進(jìn)行合并。如圖2所示。

若下一塊內(nèi)存時(shí)top chunk(top chunk一直是空閑的)，則看top chunk的大小是否超過一個(gè)閾值，如果超過一個(gè)閾值則將其釋放給OS，如圖3所示。

圖2

圖3

2Glibc內(nèi)存站崗及其原因

內(nèi)存站崗概念：

內(nèi)存站崗指的是glibc從OS申請到內(nèi)存后分配給業(yè)務(wù)模塊，業(yè)務(wù)模塊使用完畢后釋放了內(nèi)存，但是glibc沒有將這些空閑內(nèi)存釋放給OS，也就是緩存了很多空閑內(nèi)存無法歸還給系統(tǒng)的現(xiàn)象。

內(nèi)存站崗原因：

glibc設(shè)計(jì)時(shí)就確定其內(nèi)存是用于短生命周期的，因此在設(shè)計(jì)上內(nèi)存釋放給OS的時(shí)機(jī)是當(dāng)top chunk的大小超過一個(gè)閾值時(shí)會(huì)釋放top chunk的一部分內(nèi)存給OS。當(dāng)top chunk不超過閾值就不會(huì)釋放內(nèi)存給OS。

那么問題來了，若與top chunk相鄰的內(nèi)存塊一直在使用中，那么top chunk就永遠(yuǎn)也不會(huì)超過閾值，即便業(yè)務(wù)模塊釋放了大量內(nèi)存，達(dá)到幾十個(gè)G 或者上百個(gè)G，glibc也是無法將內(nèi)存還給OS的。

對于glibc來說，其有主分配和非主分配區(qū)的概念。主分配通過sbrk來增加分配區(qū)的內(nèi)存大小，而非主分配區(qū)則是通過一個(gè)或多個(gè)mmap出來的內(nèi)存塊用鏈表鏈接起來模擬主分配區(qū)的。為了更清晰的解釋內(nèi)存站崗，下面舉個(gè)例子來說明主分配區(qū)的內(nèi)存站崗，如圖4所示。

圖4

如上有(a) (c) (e) (g)內(nèi)存塊正在使用，故而導(dǎo)致了空閑內(nèi)存(b) (d) (f)無法和top chunk連成一塊更大的空閑內(nèi)存塊，glibc的閾值(64位系統(tǒng)默認(rèn)是128K)，盡管目前空閑內(nèi)存有將近130M，也無法還給OS。

接下來看非主分配區(qū)的內(nèi)存站崗，如圖 5 所示，實(shí)際的非主分配區(qū)可能有很多個(gè)heap，這里假設(shè)只有4個(gè)heap。

圖5

在定位過程中，筆者與同事討論過多次如何解決站崗。在一次討論過程中由鄧竑杰提出降低heap的size(類似于tcmalloc的做法)，雖然實(shí)測后發(fā)現(xiàn)完全沒有效果，但是為后續(xù)解決問題起到了啟示作用。

后面筆者在走讀代碼時(shí)發(fā)現(xiàn)這是glibc原生機(jī)制，同時(shí)筆者在查看內(nèi)存布局時(shí)觀察到非主分配區(qū)大量heap均為free狀態(tài)。原有機(jī)制是先釋放heap3，如果heap3有內(nèi)存在使用，盡管heap0、heap1、heap2的內(nèi)存都釋放了，那也是無法釋放給系統(tǒng)。

glibc有多個(gè)分配區(qū)，每個(gè)分配區(qū)都幾百 M 空閑內(nèi)存的話，則整個(gè)進(jìn)程占用達(dá)到幾十個(gè)G也就不奇怪了。

3Glibc內(nèi)存站崗解決方法及patch

在內(nèi)存釋放時(shí)，對于主分配區(qū)和非主分配其走的流程是不一樣的，我們64位系統(tǒng)的進(jìn)程內(nèi)存模型為經(jīng)典模式，棧是從高地址向低地址生長的。

對于主分配區(qū)的內(nèi)存站崗我還沒有遇到過，若主分配區(qū)內(nèi)存站崗，一種方法是可以嘗試madvise將主分配區(qū)的pagesize對齊的空閑內(nèi)存進(jìn)行釋放，但是這樣效果可能不太明顯。

另外一種是通過創(chuàng)建線程，然后將主線程的業(yè)務(wù)移到新線程即可，這樣主分配區(qū)就不會(huì)造成站崗了，而將站崗轉(zhuǎn)移到了非主配區(qū)，而非主分配區(qū)則是我們接下來要進(jìn)行優(yōu)化的主戰(zhàn)場。

針對非主分配區(qū)進(jìn)行兩處優(yōu)化：

a) heap0，heap1，heap2是空閑的，那么我們就可以將heap1，heap2釋放掉;

b) heap默認(rèn)是64M，降低每個(gè)heap的size(筆者測試時(shí)設(shè)置為512K)。

圖 6

這里需要特別解釋一下為什么不釋放heap0和最后一個(gè)heap3，heap0的組成如圖7所示。圖左邊是第一個(gè)heap即heap0，圖右邊是最后一個(gè)heap即heap3。

從圖中可以清晰的看到如若釋放掉heap0那么會(huì)將struct malloc_state結(jié)構(gòu)體釋放，會(huì)造成進(jìn)程崩潰。右邊這個(gè)由于有在用的內(nèi)存，也不能釋放掉。當(dāng)然如果heap3的內(nèi)存全部被釋放了，則由glibc原生代碼進(jìn)行了處理，patch不再處理。

圖 7

經(jīng)過修改glibc源碼，優(yōu)化其釋放機(jī)制，實(shí)際打流測試。

在打流到峰值后，進(jìn)程使用了20G的內(nèi)存，在停止打流后數(shù)秒內(nèi)便恢復(fù)到了打流前的內(nèi)存水平，進(jìn)程所占用的內(nèi)存基本還給系統(tǒng)了。至此，glibc內(nèi)存站崗問題得到解決。

以上我們介紹了如何解決內(nèi)存站崗的原理，紙上得來終覺淺，現(xiàn)在我們看patch源碼實(shí)現(xiàn)。

目前筆者已經(jīng)將該優(yōu)化的patch提交到開源社區(qū)審核，提交到社區(qū)的patch未對heap的size進(jìn)行修改，這是因?yàn)橄胍?jǐn)慎一些，畢竟開源的代碼使用場景較多，如有需要可自行決定heap的size。

Patch基于glibc2.17代碼

1. Index: arena.c 
2. =================================================================== 
3. --- arena.c (revision 2) 
4. +++ arena.c (working copy) 
5. @@ -652,7 +652,7 @@ 
6. 
7. static int 
8. internal_function 
9. -heap_trim(heap_info *heap, size_t pad) 
10. +heap_trim(heap_info *heap, heap_info* free_heap, size_t pad) 
11. { 
12. mstate ar_ptr = heap->ar_ptr; 
13. unsigned long pagesz = GLRO(dl_pagesize); 
14. @@ -659,7 +659,29 @@ 
15. mchunkptr top_chunk = top(ar_ptr), p, bck, fwd; 
16. heap_info *prev_heap; 
17. long new_size, top_size, extra, prev_size, misalign; 
18. + heap_info *last_heap; 
19. 
20. + /*Release heap if possible*/ 
21. + last_heap = heap_for_ptr(top_chunk); 
22. + if ((NULL != free_heap->prev) && (last_heap != free_heap)){ 
23. + p = chunk_at_offset(free_heap, sizeof(*free_heap)); 
24. + if (!inuse(p)){ 
25. + if (chunksize(p)+sizeof(*free_heap)+MINSIZE==free_heap->size){ 
26. + while (last_heap){ 
27. + if (last_heap->prev == free_heap){ 
28. + last_heap->prev == free_heap->prev; 
29. + break; 
30. + } 
31. + last_heap = last_heap->prev; 
32. + } 
33. + ar_ptr->system_mem -= free_heap->size; 
34. + arena_mem -= free_heap->size; 
35. + unlink(p, bck, fwd); 
36. + delete_heap(free_heap); 
37. + return 1; 
38. + } 
39. + } 
40. + } 
41. /* Can this heap go away completely? */ 
42. while(top_chunk == chunk_at_offset(heap, sizeof(*heap))) { 
43. prev_heap = heap->prev; 
44. Index: malloc.c 
45. =================================================================== 
46. --- malloc.c (revision 2) 
47. +++ malloc.c (working copy) 
48. @@ -915,7 +915,7 @@ 
49. # if __WORDSIZE == 32 
50. # define DEFAULT_MMAP_THRESHOLD_MAX (512 * 1024) 
51. # else 
52. - 
# define DEFAULT_MMAP_THRESHOLD_MAX (4 * 1024 * 1024 * sizeof(long)) 
53. +# define DEFAULT_MMAP_THRESHOLD_MAX (256 * 1024) 
54. # endif 
55. #endif 
56. 
57. @@ -3984,7 +3984,7 @@ 
58. heap_info *heap = heap_for_ptr(top(av)); 
59. 
60. assert(heap->ar_ptr == av); 
61. - heap_trim(heap, mp_.top_pad); 
62. + heap_trim(heap, heap_for_ptr(p), mp_.top_pad); 
63. } 
64. } 

結(jié)束語

不同的內(nèi)存管理方式均有其優(yōu)勢和缺陷，由于工作需要，筆者有幸研究過glibc、tcmalloc、uclibc內(nèi)存管理，本文討論了glibc內(nèi)存管理存在的一個(gè)共性問題，并給出可行的解決方案。

對于內(nèi)存站崗問題，一般的做法是用戶自己緩存一些長時(shí)間不釋放的內(nèi)存。另一種是干脆將glibc替換為tcmalloc。因?yàn)?tcmalloc 的 span比較小，所以站崗發(fā)生的概率極低，即便發(fā)生也就站崗一個(gè)span的大小。若由于某些原因不能用tcmalloc代替glibc的場景，如上的解決思路可以嘗試一下，該問題也困擾我們多時(shí)了，花費(fèi)了較長時(shí)間和較多精力去定位。

在glibc2.28的版本中，glibc有了tcache的特性，對于業(yè)務(wù)進(jìn)程使用大量小內(nèi)存的場景則更加容易出現(xiàn)內(nèi)存站崗問題。在撰寫本文時(shí)查看了glibc2.33版本，開源社區(qū)還未對該問題進(jìn)行修改(或許是開源社區(qū)大神認(rèn)為這不是glibc的問題，而是用戶不釋放內(nèi)存)。