引言

對于嵌入式設備來說，用戶態內存管理是一項基礎功能，目前主流的用戶態內存管理庫有glibc、uclibc、tcmalloc、jemalloc等。

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

筆者遇到的問題是基于glibc進行內存管理的64 位Linux系統。具體現象如下：設備32G物理內存，在大規格打流情況下，某用戶進程占用的物理內存暴漲至20G左右。

在停止打流后，觀察到業務模塊已經釋放了絕大部分內存，但是進程占用的物理內存依然達到16G左右，此后內存狀況一直維持該狀態，導致系統內存緊張，若疊加上其他業務則出現了OOM的現象，已排除該進程內存泄露的可能性。

1

Glibc內存分配基本原理

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

一般進程都是多線程的，當多個線程同時需要申請內存時，如果只有一個分配區，那么效率太低。

glibc為了支持多線程的內存申請釋放，會在多個線程同時需要申請內存時根據cpu核數分配一定數量的分配區，將分配區分配給線程。如果線程數量較多，則會出現多個線程爭用一個分配區的的情況，這里不展開。

內存申請基本原理：當用戶調用malloc申請內存時，glibc會查看是否已經緩存了內存，如果有緩存則會優先使用緩存內存，返回一塊符合用戶請求大小的內存塊。

如果沒有緩存或者緩存不足則會去向操作系統申請內存（可通過brk、mmap申請內存），然后切一塊內存給用戶。

內存釋放基本原理：當業務模塊使用完畢后調用free釋放內存時，glibc會檢查該內存塊虛擬地址上下內存塊的使用狀態（fast bin除外）。若其上一塊內存空閑，則與上一塊內存進行合并。若下一塊內存空閑，則與下一塊內存進行合并。如圖2所示。

若下一塊內存時top chunk（top chunk一直是空閑的），則看top chunk的大小是否超過一個閾值，如果超過一個閾值則將其釋放給OS。

2

Glibc內存站崗及其原因

內存站崗概念：

內存站崗指的是glibc從OS申請到內存后分配給業務模塊，業務模塊使用完畢后釋放了內存，但是glibc沒有將這些空閑內存釋放給OS，也就是緩存了很多空閑內存無法歸還給系統的現象。

內存站崗原因：

glibc設計時就確定其內存是用于短生命周期的，因此在設計上內存釋放給OS的時機是當top chunk的大小超過一個閾值時會釋放top chunk的一部分內存給OS。當top chunk不超過閾值就不會釋放內存給OS。

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

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

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

接下來看非主分配區的內存站崗，實際的非主分配區可能有很多個heap，這里假設只有4個heap。

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

后面筆者在走讀代碼時發現這是glibc原生機制，同時筆者在查看內存布局時觀察到非主分配區大量heap均為free狀態。原有機制是先釋放heap3，如果heap3有內存在使用，盡管heap0、heap1、heap2的內存都釋放了，那也是無法釋放給系統。

glibc有多個分配區，每個分配區都幾百 M 空閑內存的話，則整個進程占用達到幾十個G也就不奇怪了。

3

Glibc內存站崗解決方法及patch

在內存釋放時，對于主分配區和非主分配其走的流程是不一樣的，我們64位系統的進程內存模型為經典模式，棧是從高地址向低地址生長的。

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

另外一種是通過創建線程，然后將主線程的業務移到新線程即可，這樣主分配區就不會造成站崗了，而將站崗轉移到了非主配區，而非主分配區則是我們接下來要進行優化的主戰場。

針對非主分配區進行兩處優化：a） heap0，heap1，heap2是空閑的，那么我們就可以將heap1，heap2釋放掉；b） heap默認是64M，降低每個heap的size（筆者測試時設置為512K）。

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

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

經過修改glibc源碼，優化其釋放機制，實際打流測試。

在打流到峰值后，進程使用了20G的內存，在停止打流后數秒內便恢復到了打流前的內存水平，進程所占用的內存基本還給系統了。至此，glibc內存站崗問題得到解決。

以上我們介紹了如何解決內存站崗的原理，紙上得來終覺淺，現在我們看patch源碼實現。

目前筆者已經將該優化的patch提交到開源社區審核，提交到社區的patch未對heap的size進行修改，這是因為想要謹慎一些，畢竟開源的代碼使用場景較多，如有需要可自行決定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

結束語

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

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

在glibc2.28的版本中，glibc有了tcache的特性，對于業務進程使用大量小內存的場景則更加容易出現內存站崗問題。在撰寫本文時查看了glibc2.33版本，開源社區還未對該問題進行修改（或許是開源社區大神認為這不是glibc的問題，而是用戶不釋放內存）。

編輯：jq