Linux記憶體使用詳解

ysping發表於2009-08-17
我是一名程式設計師,那麼我在這裡以一個程式設計師的角度來講解Linux記憶體的使用。一提到記憶體管理,我們頭腦中閃出的兩個概念,就是虛擬記憶體,與實體記憶體。這兩個概念主要來自於linux核心的支援。

Linux
在記憶體管理上份為兩級,一級是線性區,類似於00c73000-00c88000,對應於虛擬記憶體,它實際上不佔用實際實體記憶體;一級是具體的物理頁面,它對應我們機器上的實體記憶體。
[@more@]

這裡要提到一個很重要的概念,記憶體的延遲分配。Linux核心在使用者申請記憶體的時候,只是給它分配了一個線性區(也就是虛存),並沒有分配實際實體記憶體;只有當使用者使用這塊記憶體的時候,核心才會分配具體的物理頁面給使用者,這時候才佔用寶貴的實體記憶體。核心釋放物理頁面是透過釋放線性區,找到其所對應的物理頁面,將其全部釋放的過程。

char *p=malloc(2048) //
這裡只是分配了虛擬記憶體2048,並不佔用實際記憶體。
strcpy(p,”123”) //
分配了物理頁面,雖然只是使用了3個位元組,但記憶體還是為它分配了2048位元組的實體記憶體。
free(p) //
透過虛擬地址,找到其所對應的物理頁面,釋放物理頁面,釋放線性區。我們知道使用者的程式和核心是執行在不同的級別,程式與核心之間的通訊是透過系統呼叫來完成的。程式在申請和釋放記憶體,主要透過brk,sbrk,mmap,unmmap這幾個系統呼叫,傳遞的引數主要是對應的虛擬記憶體。注意一點,在程式只能訪問虛擬記憶體,它實際上是看不到核心實體記憶體的使用,這對於程式是完全透明的。

glibc
記憶體管理器那麼我們每次呼叫malloc來分配一塊記憶體,都進行相應的系統呼叫呢?答案是否定的,這裡我要引入一個新的概念,glibc的記憶體管理器。我們知道mallocfree等函式都是包含在glibc庫裡面的庫函式,我們試想一下,每做一次記憶體操作,都要呼叫系統呼叫的話,那麼程式將多麼的低效。實際上glibc採用了一種批發和零售的方式來管理記憶體。glibc每次透過系統呼叫的方式申請一大塊記憶體(虛擬記憶體),當程式申請記憶體時,glibc就從自己獲得的記憶體中取出一塊給程式。記憶體管理器面臨的困難我們在寫程式的時候,每次申請的記憶體塊大小不規律,而且存在頻繁的申請和釋放,這樣不可避免的就會產生記憶體碎塊。而記憶體碎塊,直接會導致大塊記憶體申請無法滿足,從而更多的佔用系統資源;如果進行碎塊整理的話,又會增加cpu的負荷,很多都是互相矛盾的指標,這裡我就不細說了。我們在寫程式時,涉及記憶體時,有兩個概念heapstack。傳統的說法stack的記憶體地址是向下增長的,heap的記憶體地址是向上增長的。函式mallocfree,主要是針對heap進行操作,由程式設計師自主控制記憶體的訪問。在這裡heap的記憶體地址向上增長,這句話不完全正確。

glibc
對於heap記憶體申請大於128k的記憶體申請,glibc採用mmap的方式向核心申請記憶體,這不能保證記憶體地址向上增長;小於128k的則採用brk,對於它來講是正確的。128k的閥值,可以透過glibc的庫函式進行設定。這裡我先講大塊記憶體的申請,也即對應於mmap系統呼叫。對於大塊記憶體申請,glibc直接使用mmap系統呼叫為其劃分出另一塊虛擬地址,供程式單獨使用;在該塊記憶體釋放時,使用unmmap系統呼叫將這塊記憶體釋放,這個過程中間不會產生記憶體碎塊等問題。針對小塊記憶體的申請,在程式啟動之後,程式會獲得一個heap底端的地址,程式每次進行記憶體申請時,glibc會將堆頂向上增長來擴充套件記憶體空間,也就是我們所說的堆地址向上增長。在對這些小塊記憶體進行操作時,便會產生記憶體碎塊的問題。實際上brksbrk系統呼叫,就是調整heap頂地址指標。那麼heap堆的記憶體是什麼時候釋放呢?glibc發現堆頂有連續的128k的空間是空閒的時候,它就會透過brksbrk系統呼叫,來調整heap頂的位置,將佔用的記憶體返回給系統。這時,核心會透過刪除相應的線性區,來釋放佔用的實體記憶體。下面我要講一個記憶體空洞的問題:一個場景,堆頂有一塊正在使用的記憶體,而下面有很大的連續記憶體已經被釋放掉了,那麼這塊記憶體是否能夠被釋放?其對應的實體記憶體是否能夠被釋放?很遺憾,不能。這也就是說,只要堆頂的部分申請記憶體還在佔用,我在下面釋放的記憶體再多,都不會被返回到系統中,仍然佔用著實體記憶體。為什麼會這樣呢?這主要是與核心在處理堆的時候,過於簡單,它只能透過調整堆頂指標的方式來調整調整程式佔用的線性區;而又只能透過調整線性區的方式,來釋放記憶體。所以只要堆頂不減小,佔用的記憶體就不會釋放。提一個問題:

char *p=malloc(2);
free(p)
為什麼申請記憶體的時候,需要兩個引數,一個是記憶體大小,一個是返回的指標;而釋放記憶體的時候,卻只要記憶體的指標呢?這主要是和glibc的記憶體管理機制有關。glibc中,為每一塊記憶體維護了一個chunk的結構。glibc在分配記憶體時,glibc先填寫chunk結構中記憶體塊的大小,然後是分配給程式的記憶體。

chunk ------size
p------------ content
在程式釋放記憶體時,只要 指標-4 便可以找到該塊記憶體的大小,從而釋放掉。注:glibc在做記憶體申請時,最少分配16個位元組,以便能夠維護chunk結構。

glibc
提供的除錯工具:為了方便除錯,glibc 為使用者提供了 malloc 等等函式的鉤子(hook),如 __malloc_hook對應的是一個函式指標,void *function (size_t size, const void *caller)其中 caller 是呼叫 malloc 返回值的接受者(一個指標的地址)。另外有 __malloc_initialize_hook函式指標,僅僅會呼叫一次(第一次分配動態記憶體時)。(malloc.h一些使用 malloc 的統計量(SVID 擴充套件)可以用 struct mallinfo 儲存,可呼叫獲得。

struct mallinfo mallinfo (void)
如何檢測 memory leakageglibc 提供了一個函式void mtrace (void)及其反作用void muntrace (void)這時會依賴於一個環境變數 MALLOC_TRACE 所指的檔案,把一些資訊記錄在該檔案中用於偵測 memory leakage,其本質是安裝了前面提到的 hook。一般將這些函式用#ifdef DEBUGGING 包裹以便在非除錯態下減少開銷。產生的檔案據說不建議自己去讀,而使用 mtrace 程式(perl 指令碼來進行分析)。下面用一個簡單的例子說明這個過程,這是源程式:

#include
#include
#include
intmain( int argc, char *argv[] )
{
int *p, *q ;
#ifdef DEBUGGING
mtrace( ) ;
#endif
p = malloc( sizeof( int ) ) ;
q = malloc( sizeof( int ) ) ;
printf( "p = %pnq = %pn", p, q ) ;
*p = 1 ;
*q = 2 ;
free( p ) ;
return 0 ;
}
很簡單的程式,其中 q 沒有被釋放。我們設定了環境變數後並且 touch 出該檔案執行結果如下:

p = 0x98c0378q = 0x98c0388
該檔案內容如下

= Star
t@./test30:[0x8048446] + 0x98c0378 0x4
@ ./test30:[0x8048455] + 0x98c0388 0x4
@ ./test30:[0x804848f] - 0x98c0378
到這裡我基本上講完了,我們寫程式時,資料部分記憶體使用的問題。程式碼佔用的記憶體資料部分佔用記憶體,那麼我們寫的程式是不是也佔用記憶體呢?linux中,程式的載入,涉及到兩個工具,linker loaderLinker主要涉及動態連結庫的使用,loader主要涉及軟體的載入。

1
exec執行一個程式

2
elf為現在非常流行的可執行檔案的格式,它為程式執行劃分了兩個段,一個段是可以執行的程式碼段,它是隻讀,可執行;另一個段是資料段,它是可讀寫,不能執行。

3
loader會啟動,透過mmap系統呼叫,將程式碼端和資料段對映到記憶體中,其實也就是為其分配了虛擬記憶體,注意這時候,還不佔用實體記憶體;只有程式執行到了相應的地方,核心才會為其分配實體記憶體。

4
loader會去查詢該程式依賴的連結庫,首先看該連結庫是否被對映進記憶體中,如果沒有使用mmap,將程式碼段與資料段對映到記憶體中,否則只是將其加入程式的地址空間。這樣比如glibc等庫的記憶體地址空間是完全一樣。因此一個2M的程式,執行時,並不意味著為其分配了2M的實體記憶體,這與其執行了的程式碼量,與其所依賴的動態連結庫有關。執行過程中連結動態連結庫與編譯過程中連結動態庫的區別。我們呼叫動態連結庫有兩種方法:一種是編譯的時候,指明所依賴的動態連結庫,這樣loader可以在程式啟動的時候,來所有的動態連結對映到記憶體中;一種是在執行過程中,透過dlopendlfree的方式載入動態連結庫,動態將動態連結庫載入到記憶體中。這兩種方式,從程式設計角度來講,第一種是最方便的,效率上影響也不大,在記憶體使用上有些差別。第一種方式,一個庫的程式碼,只要執行過一次,便會佔用實體記憶體,之後即使再也不使用,也會佔用實體記憶體,直到程式的終止。第二中方式,庫程式碼佔用的記憶體,可以透過dlfree的方式,釋放掉,返回給實體記憶體。這個差別主要對於那些壽命很長,但又會偶爾呼叫各種庫的程式有關。如果是這類程式,建議採用第二種方式呼叫動態連結庫。佔用記憶體的測量測量一個程式佔用了多少記憶體,linux為我們提供了一個很方便的方法,/proc目錄為我們提供了所有的資訊,實際上top等工具也透過這裡來獲取相應的資訊。

/proc/meminfo
機器的記憶體使用資訊
/proc/pid/maps pid
為程式號,顯示當前程式所佔用的虛擬地址。
/proc/pid/statm
程式所佔用的記憶體
[root@localhost ~]# cat /proc/self/statm
654 57 44 0 0 334 0
輸出解釋

CPU
以及CPU0。。。的每行的每個引數意思(以第一行為例)為:引數 解釋 /proc//status
Size (pages)
任務虛擬地址空間的大小
VmSize/4
Resident(pages)
應用程式正在使用的實體記憶體的大小
VmRSS/4
Shared(pages)
共享頁數
0
Trs(pages)
程式所擁有的可執行虛擬記憶體的大小
VmExe/4
Lrs(pages)
被映像到任務的虛擬記憶體空間的庫的大小
VmLib/4
Drs(pages)
程式資料段和使用者態的棧的大小 (VmData+ VmStk
4
dt(pages) 04
檢視機器可用記憶體


/proc/28248/>free
total used free shared buffers cached
Mem: 1023788 926400 97388 0 134668 503688
-/+ buffers/cache: 288044 735744
Swap: 1959920 89608 1870312
我們透過free命令檢視機器空閒記憶體時,會發現free的值很小。這主要是因為,在linux中有這麼一種思想,記憶體不用白不用,因此它儘可能的cachebuffer一些資料,以方便下次使用。但實際上這些記憶體也是可以立刻拿來使用的。所以 空閒記憶體=free+buffers+cached=total-used檢視程式使用的記憶體檢視一個程式使用的記憶體,是一個很令人困惑的事情。因為我們寫的程式,必然要用到動態連結庫,將其加入到自己的地址空間中,但是/proc/pid/statm統計出來的資料,會將這些動態連結庫所佔用的記憶體也簡單的算進來。這樣帶來的問題,動態連結庫佔用的記憶體有些是其他程式使用時佔用的,卻算在了你這裡。你的程式中包含了子程式,那麼有些動態連結庫重用的記憶體會被重複計算。因此要想準確的評估一個程式所佔用的記憶體是十分困難的,透過寫一個module的方式,來準確計算某一段虛擬地址所佔用的記憶體,可能對我們有用。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/670493/viewspace-1026079/,如需轉載,請註明出處,否則將追究法律責任。

相關文章