在linux下,使用top,ps等命令查看進程的內(nèi)存使用情況時,經(jīng)??吹絍IRT,RES,SHR等,他們都代表什么意思呢?不同的大小對進程有什么影響呢?這篇文章將來聊一聊這個問題。閱讀本篇前建議先閱讀Linux內(nèi)存管理,了解一些Linux下內(nèi)存的基本概念,如什么是anonymous和file backed映射等。
查看進程所使用的內(nèi)存
在進程的眼里,所有的內(nèi)存都是虛擬內(nèi)存,但是這些虛擬內(nèi)存所對應的物理內(nèi)存是多少呢?正如我們在Linux內(nèi)存管理中所介紹的那樣,并不是每塊虛擬內(nèi)存都有對應的物理內(nèi)存,可能對應的數(shù)據(jù)在磁盤上的一個文件中,或者交換空間上的一塊區(qū)域里。一個進程真正的物理內(nèi)存使用情況只有內(nèi)核知道,我們只能通過內(nèi)核開放的一些接口來獲取這些統(tǒng)計數(shù)據(jù)。
top
先看看top的輸出(top用到的數(shù)據(jù)來自于/proc/[pid]/statm),這里只是摘錄了幾條數(shù)據(jù):
VIRT:進程所使用的虛擬內(nèi)存大小
RES:系統(tǒng)為虛擬內(nèi)存分配的物理內(nèi)存大小,包括file backed和anonymous內(nèi)存,其中anonymous包含了進程自己分配和使用的內(nèi)存,以及和別的進程通過mmap共享的內(nèi)存;而file backed的內(nèi)存就是指加載可執(zhí)行文件和動態(tài)庫所占的內(nèi)存,以及通過private方式調(diào)用mmap映射文件所使用的內(nèi)存(當在內(nèi)存中修改了這部分數(shù)據(jù)且沒有寫回文件,那么這部分內(nèi)存就變成了anonymous),這部分內(nèi)存也可能跟別的進程共享。
SHR:RES的一部分,表示和別的進程共享的內(nèi)存,包括通過mmap共享的內(nèi)存和file backed的內(nèi)存。當通過prive方式調(diào)用mmap映射一個文件時,如果沒有修改文件的內(nèi)容,那么那部分內(nèi)容就是SHR的,一旦修改了文件內(nèi)容且沒有寫回文件,那么這部分內(nèi)存就是anonymous且非SHR的。
%MEM:等于RES/total*100%,這里total指總的物理內(nèi)存大小。
注意:由于SHR可能會被多個進程所共享,所以系統(tǒng)中所有進程的RES加起來可能會超過總的物理內(nèi)存數(shù)量,由于同樣的原因,所有進程的%MEM總和可能超過100%。
從上面的分析可以看出,VIRT的參考意義不大,它只能反應出程序的大小,而RES也不能完全的代表一個進程真正占用的內(nèi)存空間,因為它里面還包含了SHR的部分,比如三個bash進程共享了一個libc動態(tài)庫,那么libc所占用的內(nèi)存算誰的呢?三個進程平分嗎?如果啟動一個bash占用了4M的RES,其中3M是libc占用的,由于三個進程都共享那3M的libc,那么啟動3個bash實際占用的內(nèi)存將是3*(4-3)+3=6M,但是如果單純的按照RES來算的話,三個進程就用了12M的空間。所以理解RES和SHR這兩個數(shù)據(jù)的含義對我們在評估一臺服務器能跑多少個進程時尤其重要,不要一看到apache的進程占用了20M,就認為系統(tǒng)能跑的apache進程數(shù)就是總的物理內(nèi)存數(shù)除以20M,其實這20M里面有可能有很大一部分是SHR的。
注意:top命令輸出中的RES和pmap輸出中的RSS是一個東西。
pmap
上面top命令只是給出了一個進程大概占用了多少的內(nèi)存,而pmap能更詳細的給出內(nèi)存都是被誰占用了。pmap命令輸出的內(nèi)容來自于/proc/[pid]/maps和/proc/[pid]/smaps這兩個文件,第一個文件包含了每段的一個大概描述,而后一個文件包含了更詳細的信息。
這里用pmap看看當前bash的內(nèi)存使用情況,:
這里第一列是內(nèi)存的起始地址,第二列是mapping的地址大小,第三列是這段內(nèi)存的訪問權(quán)限,最后一列是mapping到的文件。這里的地址都是虛擬地址,大小也是虛擬地址大小。
這里的輸出有很多的[ anon ]行,表示在磁盤上沒有對應的文件,這些一般都是可執(zhí)行文件或者動態(tài)庫里的bss段。當然有對應文件的mapping也有可能是anonymous,比如文件的數(shù)據(jù)段。關(guān)于程序的數(shù)據(jù)段和bss段的介紹請參考elf的相關(guān)資料。
上面可以看到bash、libc-2.23.so等文件出現(xiàn)了多行,但每行的權(quán)限不一樣,這是因為每個動態(tài)庫或者可執(zhí)行文件里面都分很多段,有只能讀和執(zhí)行的代碼段,有能讀寫的數(shù)據(jù)段,還有比如這一行“00007f1fa153b000 16K rw--- [ anon ]”,就是它上面一行l(wèi)ibc-2.23.so的bss段。
[ stack ]表示進程用到的??臻g,而heap在這里看不到,因為pmap默認情況下不單獨標記heap出來,由于heap是anonymous,所以從這里的大小可以推測出來,heap就是“0000000000be4000 1544K rw--- [ anon ]”。
其實從上面的結(jié)果根本看不出實際上每段占用了多少物理內(nèi)存,要想看到RSS,需要使用-X參數(shù),下面看看更詳細的輸出:
權(quán)限字段多了一個s和p的標記,s表示是和別人共享的內(nèi)存空間,讀寫會影響到其他進程,而p表示這是自己私有的內(nèi)存空間,讀寫這部分內(nèi)存不會對其他進程造成影響。
輸出標示出了[heap]段,并且也說明了后面幾個[anon]代表的什么意思(vvar,vdso,vsyscall都是映射到內(nèi)核的特殊段),mapping字段為空的都是上一行mapping文件里面的bss段(可是gconv-modules.cache后面有兩行anonymous mapping,可能跟共享內(nèi)存有關(guān)系,沒有深究)。
Anonymous列標示出了哪些是并且有多少是Anonymous方式映射的物理內(nèi)存,其大小小于等于RSS
RSS列表示實際占用的物理內(nèi)存大小
top命令輸出的SHR內(nèi)存
最后來看看top命令輸出的SHR到底由pmap的哪些輸出構(gòu)成
從上面的輸出可看出SHR ≈ RES - writeable/private,其中writeable/private主要包含stack和heap以及可執(zhí)行文件和動態(tài)庫的data和bss段,而stack+heap=1544+132=1675,這已經(jīng)占了絕大部分,從而data和bss段之類的基本上可以忽略了,所以一般情況下,SHR ≈ RES - [heap] - [stack],由于stack一般都比較小,上面的等式可以進一步約等于:SHR ≈ RES - [heap]。
總結(jié)
top命令能看到一個進程占用的虛擬內(nèi)存空間、物理內(nèi)存空間以及和別的進程共享的物理內(nèi)存空間,這里共享的空間包括通過mmap共享的內(nèi)存以及共享的可執(zhí)行文件以及動態(tài)庫。而mmap命令能看到更詳細的信息,比如可執(zhí)行文件和它所鏈接的動態(tài)庫大小,以及物理內(nèi)存都是被哪些段給占用了。
進程占用的虛擬地址空間大小跟程序的規(guī)模有關(guān),除了stack和heap段,其他段的大小基本上都是固定的,并且在程序鏈接的時候就已經(jīng)確定了,所以基本上只要關(guān)注stack和heap段就可以了,由于stack相對heap來說很小,所以只要沒什么stack異常,只需要關(guān)注heap。
在實際的工作過程中,其實我們更關(guān)心的是RSS用了多少,都被誰用了,簡單點說,如果我們沒有同時啟動多個進程(同一個程序),RSS就是一個很好的實際物理內(nèi)存使用參考值,但如果是像apache那樣同時跑很多個進程,那么RSS減去SHR所占用的空間就是一個很好的實際物理內(nèi)存占用參考值,當然這都是大概估算值。
要想精確評估一個進程到底占了多少內(nèi)存,還是很難的,需要對進程的每個段有深入的理解,尤其是SHR部分都有哪些進程在一起共享,不過現(xiàn)在服務器上的內(nèi)存都是以G為單位的,所以一般情況下大概的估算一下加上合理的測試就能滿足我們的需求了。
如需購買云服務器,推薦創(chuàng)新互聯(lián)云:http://muchs.cn/cloud/
名稱欄目:云服務器:使用top,ps等命令查看進程的內(nèi)存使用情況
文章源于:http://muchs.cn/article4/cjhiie.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站制作、網(wǎng)站營銷、ChatGPT、全網(wǎng)營銷推廣、外貿(mào)建站、App設計
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)