引言

對(duì)于嵌入式設(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)存站崗問題形成原因展開討論，并對(duì)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)存泄露的可能性。

1

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

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

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

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

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

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

內(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。

2

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

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

內(nèi)存站崗指的是glibc從OS申請(qǐng)到內(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的。

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

如上有（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)存站崗，實(shí)際的非主分配區(qū)可能有很多個(gè)heap，這里假設(shè)只有4個(gè)heap。

在定位過程中，筆者與同事討論過多次如何解決站崗。在一次討論過程中由鄧竑杰提出降低heap的size（類似于tcmalloc的做法），雖然實(shí)測(cè)后發(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也就不奇怪了。

3

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

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

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

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

針對(duì)非主分配區(qū)進(jìn)行兩處優(yōu)化：a） heap0，heap1，heap2是空閑的，那么我們就可以將heap1，heap2釋放掉；b） heap默認(rèn)是64M，降低每個(gè)heap的size（筆者測(cè)試時(shí)設(shè)置為512K）。

這里需要特別解釋一下為什么不釋放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不再處理。

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

在打流到峰值后，進(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未對(duì)heap的size進(jìn)行修改，這是因?yàn)橄胍?jǐn)慎一些，畢竟開源的代碼使用場景較多，如有需要可自行決定heap的size。

Patch基于glibc2.17代碼

1. Index： arena.c2. ===================================================================3. --- arena.c （revision 2）4. +++ arena.c （working copy）5. @@ -652，7 +652，7 @@6.7. static int8. internal_function9. -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.c45. ===================================================================46. --- malloc.c （revision 2）47. +++ malloc.c （working copy）48. @@ -915，7 +915，7 @@49. # if __WORDSIZE == 3250. # define DEFAULT_MMAP_THRESHOLD_MAX （512 * 1024）51. # else52. -# define DEFAULT_MMAP_THRESHOLD_MAX （4 * 1024 * 1024 * sizeof（long））53. +# define DEFAULT_MMAP_THRESHOLD_MAX （256 * 1024）54. # endif55. #endif56.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. }

4

結(jié)束語

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

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

編輯：jq