linux進程內存空間

Ⅰ linux怎麼查看每個進程佔用的內存

ps
aux
user
pid
%cpu
%mem
vsz
rss
tty
stat
start
time
command
●
user，進程所有者的用戶名。
●
pid，進程號，可以唯一標識該進程。
●
%cpu，進程自最近一次刷新以來所佔用的cpu時間和總時間的百分比。
●
%mem，進程使用內存的百分比。
●
vsz，進程使用的虛擬內存大小，以k為單位。
●
rss，進程佔用的物理內存的總數量，以k為單位。
●
tty，進程相關的終端名。
●
stat，進程狀態，用(r--運行或准備運行；s--睡眠狀態；i--空閑；z--凍結；d--不間斷睡眠；w-進程沒有駐留頁；t停止或跟蹤。)這些字母來表示。
●
start，進程開始運行時間。
●
time，進程使用的總cpu時間。
●
command，被執行的命令行。

Ⅱ linux的虛擬內存是4G，而每個進程都有自己獨立的4G內存空間，怎麼理解

一個進程用到的虛擬地址是由內存區域表來管理的，實際用不了4G。而用到的內存區域，會通過頁表映射到物理內存。所以每個進程都可以使用同樣的虛擬內存地址而不沖突，因為它們的物理地址實際上是不同的。

內核用的是3G以上的1G虛擬內存地址，其中896M是直接映射到物理地址的，128M按需映射896M以上的所謂高位內存。各進程用的是同一個內核，什麼叫「都運行內核」？

Ⅲ Linux進程的內存使用解析

進程XXX佔用了多少內存？這是個經常被問到，也經常被答錯的問題。linux進程的內存分配是個比較復雜的話題，而linux上的工具往往把這個問題過分簡單化，因此引出不少誤解和困惑。首先把ps,
top這類工具扔掉，然後看這么一個簡單程序：[root@pczou
pczou]#
cat
./prog.c#i
nclude#i
nclude#i
nclude#i
nclude#define
ONEM
(1024*1024)
www.shiwu.com
int
func(){char
s[16*ONEM];char*
p;p
=
malloc(32*ONEM);pause();return
0;}int
main(){printf(pid:
%d/n,
getpid());func();return
0;}其中func()這個函數分配了32MB的內存，以及16MB的堆棧。運行一下這個prog程序，prog會停在pause()的位置，看看ps怎麼說：USER
PID
%CPU
%MEM
VSZ
RSS
TTY
STAT
START
TIME
COMMANDroot
4238
0.0
0.0
52396
352
pts/0
S
21:29
0:00
./progVSZ指的是進程內存空間的大小，這里是52396KB;RSS指的是駐留物理內存中的內存大小，這里是352KB。一般系統管理員知道VSZ並不代表進程真正用到的內存，因為有些空間會僅在頁表中掛個名，也就是說只是虛擬存在著，只有真正用到的時候內核才會把虛擬頁面和真正的物理頁面映射起來。比如，prog.c中用malloc()分配的32MB內存，由於程序中並沒有用到這些內存，沒有物理內存被分配，也就不應算到進程的帳上。
www.shiwu.com
進程的內存使用情況比較復雜，這是因為：進程所申請的內存不一定真正會被用到真正用到了的內存也不一定是只有該進程自己在用
(比如動態共享庫)所以酒足飯飽結帳的時候，飯館打出的帳單中往往漏洞百出，不是計入了沒上的菜，就是一個菜算了兩份錢。而ps給出的就是這樣的糊塗帳單，不足為憑。算清楚帳的唯一辦法是把每個菜都仔細過一遍，看看有沒有上，有沒有重復。下面的帳單要清楚多了：Virtual
memory
:
52396
KBEffective
VM
:
52120
KBMapped
:
352
KBEffective
mapped:
76.6
KBSole
use
:
72
KBPer
file
memory
useld-2.3.4.so
:
VM
94208
B,
M
90112
B,
S
8192
Bprog
:
VM
8192
B,
M
8192
B,
S
8192
Blibc-2.3.4.so
:
VM
1180
KB,
M
221184
B,
S
16384
B可以看出，雖然虛擬地址空間是52396KB，實際映射(a.k.a.
分配)的空間是352KB，這和ps給出的結果一致。再看Effective
Mapped這個值，僅為76.6
KB。這個值的計算方法是：有效的實際使用內存
=
該進程獨占的內存
+
共享的內存A
/共享A的進程數目
+
共享的內存B
/共享B的進程數目
+
...比如對於一個kde應用程序kontact，它用的Qt庫的虛擬地址空間為
7M，而實際映射的空間有4.5M，也就是說真正給
Qt分配物理內存大小為4.5M。假設有10個KDE應用正在運行，那麼記到kontact帳上的就不應該是4.5M，而是A-A之後的0.45M。這么算帳雖然並不十分准確，但Effective
Mapped已經足以說明進程所佔用內存的實際大小了。
www.shiwu.com
OK，最後用這個方法給系統中所有進程都結下帳：從上面的統計結果可以看出：雖然firefox的佔用虛擬空間是最大的，但其實際佔用的內存卻比X
Server要少。firefox
的實際佔用的內存和其RSS
(a.k.a.
mapped)差別不大，佔RSS的99%;而kontact的實際佔用內存卻僅佔RSS的63%，有27%的內存是共享的。由此可以粗略看出我用的窗口管理器是KDE而非Gnome，why?
因為Qt之類的共享庫被很多KDE進程分擔了。sole值可以理解為private
mapped，也就是這個進程退出後可能被釋放的內存
(對於非匿名的映射頁面可能還會存留一段時間)。作者
railon

Ⅳ linux 下怎麼查看一個進程佔用內存大小

這里介紹下查看一個進程佔用內存大小的方法。

1、首先單擊桌面左上角的應用程序，選擇系統工具選項，如下圖所示。

Ⅳ linux進程內存相關

3種地址：虛擬地址、物理地址、邏輯地址
物理地址：內存的電路地址，對應內存地址線上的高低電平，物理可見的。
虛擬地址： 分頁機制 的產物，也叫線性地址，是進程能看見的地址。
邏輯地址： 分段機制 的產物，屬於inter cpu的歷史遺留問題，linux可以當做不存在。
3種地址的轉換：進程訪問邏輯地址，linux內核根據分段機制裝換成虛擬地址，然後把進程的頁表和虛擬地址都告訴cpu，cpu就可以根據分頁機制將虛擬地址裝換成物理地址，然後訪問內存。
linux內核中巧妙地屏蔽里分段機制，就是邏輯地址等於虛擬地址，訪問內存只需要利用分頁機制把虛擬地址轉換成物理地址。

linux會為每個進程創建自己的虛擬地址空間，就是進程地址空間，64位系統就是128T的內存空間。需要注意的是，虛擬地址就是假的，一開始不和物理地址對應，也就是說不佔用物理內存，只有當虛擬地址有寫入操作是，內核會觸發缺頁，分配真實的物理地址給虛擬地址。物理地址的管理可參考 內核內存管理

從進程空間看，用戶態閑置內存有3塊，Stack、Memory Mapping Region、Heap，Stack是程序函數調用運行時需要的，不可控，能自由分配的內存就剩Memory Mapping Region、Heap了，linux系統提供的內存分配函數就是針對這兩個區域的。
Heap操作函數：int brk(void *addr)、void *sbrk(intptr_t increment)
Memory Mapping Region操作函數：mmap()、munmap()

當然進程可以直接使用系統調用去申請內存，但是如果不管理的話，經過大量的申請和釋放，會把進程空間切割的亂七八糟，導致不能申請大塊的連續空間，為此就出現了內存管理模塊，封裝了系統調用，對進程提供malloc和free等高級函數。實際上，除了一些特殊程序，我們也很少用系統調用，一般都是使用內存管理模塊提供的malloc和free，關系如下圖：

內存管理模塊用各種好處，例如不會每次操作都去執行系統調用，減少內存碎片的產生等等。
當然也有很多實現方式，例如常用的glibc的Ptmalloc，google的tcmalloc，facebook的jemalloc等。各有各的應用場景，blablabla....
使用時，gcc默認會鏈接glibc的，如果想使用其他lib，gcc鏈接時指定就能覆蓋掉glibc的。

我們重點講Ptmalloc，從而啟發程序員在寫程序時多考慮下內存分配情況，可以選擇或自己實現適合自己程序的內存管理lib。
Ptmalloc的歷史發展，blablabla......，Ptmalloc採取內存池管理，進程malloc時，通過brk（小於128K的內存）、mmap（大內存）從系統獲取地址空間，給進程使用，進程free時，不會立即通過brk、munmap將地址空間還給系統，會自己維護起來，叫做空閑內存，這些空閑內存在進程再次malloc時，還會被分出去，並且空閑內存會在特定條件下合並起來還給系統。

內存分配區，管理了一片內存，對外分發和回收，可以理解為一個內存池，分main arena和non main arena。
main arena：最早的分配區，管理著所有可分配的內存，通過brk，mmap等系統調用向系統申請內存。注意只有main arena可以操作Heap。
non main arena：由於多線程的出現，如果多有線程都操作main arena就會有競爭，需要加鎖控制，所以出現了non main arena，通過mmap向main arena申請一大塊內存，然後自己管理，可以理解為內存分銷商。
只有主線程在main arena上申請內存，子線程在non main arena上，non main arena的個數是有上限的，所以non main arena允許多個子線程共用，這樣就涉及到加鎖，所以程序涉及應避免子線程個數太多。

進程申請到的一塊內存叫做一個內存片，arena內部使用chunk數據結構來描述內存片，包括進程正在使用的內存片，和進程free掉的空閑內存片

A：是否main arena內存
M：使用mmap內存
P：上一塊是否被使用
size of previous chunk：上一塊沒有被使用時，表示上塊長度，被使用時是上塊用來存User data的。
Size of chunk：就是下一塊的size of previous chunk，釋放時填上本塊長度，供下塊合並用。

分給進程的內存片arena可以不管，但是進程free回來的，arena需要通過一定方式組織起來，方便進程再次使用。組織方式有下面幾種：

bins是個數組，包含128個bin，每個bin是個鏈表，分small bin和large bin兩種，各64個，small bin中chunk大小固定，兩個相鄰的small bin中的chunk大小相差8bytes，large bin中chunk大小是一定范圍內的，其中的chunk按大小排列。
空閑chunk按大小選擇合適的bin，按新舊順序掛到鏈表上，優先分配舊的chunk。

不大於max_fast （默認值為64B）的chunk被釋放後，首先會被放到fast bins 中，fast bins中的chunk並不改變它的使用標志P。這樣也就無法將它們合並，當需要給用戶分配的chunk小於或等於max_fast時，ptmalloc首先會在fast bins中查找相應的空閑塊。在特定的時候，ptmalloc會遍歷fast bins中的chunk，將相鄰的空閑chunk進行合並，並將合並後的chunk加入unsorted bin中。

進行malloc時，如果在fast bins中沒有找到合適的chunk，則ptmalloc會先在unsorted bin中查找合適的空閑chunk，如果unsorted bin不能滿足分配要求。malloc便會將unsorted bin中的chunk加入bins中。然後再從bins中繼續進行查找和分配過程。從這個過程可以看出來，unsorted bin可以看做是bins的一個緩沖區，增加它只是為了加快分配的速度。

前面的bin中都是回收回來的內存，top chunk才是內存的初始來源，每個arena都有一個top chunk，用來管理Heap的，Heap會在arena第一次分配內存時初始化，會分配一塊(chunk_size + 128K) align 4K的空間（132K）作為初始的Heap，top chunk占據整個空間，每次分配會在低地址出切出一片，如下圖：

回收時，只有和top chunk相連的內存才能和top chunk合並，才能進而還給系統。

子線程Heap：在main arena中mmap出64M的空間，叫做sub-heap，再在sub-heap上初始化Heap。
主線程的Heap才是真Heap，使用進程Heap，使用brk申請內存。

子線程的heap不夠用時，會在申請新的sub-heap，和老的sub-heap單向鏈表連起來，top chunk會搬到新sub-heap上。

描述mmap出來的內存，單獨管理，free時按閾值來決定是否munmap，有動態調整閾值功能，防止太頻繁的mmap和munmap。本文不關注。

即最後一次small request中因分割而得到的剩餘部分，它有利於改進引用局部性，也即後續對 small chunk 的 malloc 請求可能最終被分配得彼此靠近。
當用戶請求 small chunk而無法從small bin和unsorted bin得到時，會在large bin中找最合適的chunk，然後做切割，返回給用戶的User chunk，剩下的是Remainder chunk添加到unsorted bin中。這一Remainder chunk就將成為last remainder chunk。

下一塊為高地址，前一塊為低地址。

Glibc內存管理 華庭（庄明強）