正確理解linux記憶體應用

來源:互聯網
上載者:User

下面轉自:http://www.chinaunix.net/jh/4/615686.html

Linux的記憶體管理,實際上跟windows的記憶體管理有很相像的地方,都是用虛擬記憶體這個的概念,說到這裡不得不罵MS,為什麼在很多時候還有很大的實體記憶體的時候,卻還是用到了pagefile. 所以才經常要跟一幫人吵著說Pagefile的大小,以及如何分配這個問題,在Linux大家就不用再吵什麼swap大小的問題,我個人認為,swap設個512M已經足夠了,如果你問說512M的SWAP不夠用怎麼辦?只能說大哥你還是加記憶體吧,要不就檢查你的應用,是不是真的出現了memory leak.
夜也深了,就不再說廢話了。

在Linux下查看記憶體我們一般用command free
[root@nonamelinux ~]# free
         total       used       free     shared    buffers     cached
Mem:    386024     377116    8908      0      21280     155468
-/+ buffers/cache:     200368    185656
Swap:    393552        0      393552
下面是對這些數值的解釋:
第二行(mem):
total:總計實體記憶體的大小。
used:已使用多大。
free:可用有多少。
Shared:多個進程共用的記憶體總額。
Buffers/cached:磁碟緩衝的大小。
第三行(-/+ buffers/cached):
used:已使用多大。
free:可用有多少。
第四行就不多解釋了。
區別:
第二行(mem)的used/free與第三行(-/+ buffers/cache) used/free的區別。
這兩個的區別在於使用的角度來看,第一行是從OS的角度來看,因為對於OS,buffers/cached 都是屬於被使用,所以他的可用記憶體是8908KB,已用記憶體是377116KB,其中包括,核心(OS)使用+Application(X,oracle,etc)使用的+buffers+cached. 
第三行所指的是從應用程式角度來看,對於應用程式來說,buffers/cached 是等於可用的,因為buffer/cached是為了提高檔案讀取的效能,當應用程式需在用到記憶體的時候,buffer/cached會很快地被回收。
所以從應用程式的角度來說,可用記憶體=系統free memory+buffers+cached.
如上例:
185656=8908+21280+155468
接下來解釋什麼時候記憶體會被交換,以及按什麼方交換。
當可用記憶體少於額定值的時候,就會開會進行交換.
如何看額定值(RHEL4.0):
#cat /proc/meminfo
交換將通過三個途徑來減少系統中使用的物理頁面的個數: 
1.減少緩衝與頁面cache的大小,
2.將系統V類型的記憶體頁面交換出去, 
3.換出或者丟棄頁面。(Application 佔用的記憶體頁,也就是實體記憶體不足)。
事實上,少量地使用swap是不是影響到系統效能的。

 nonameboy 回複於:2005-09-22 00:54:46

下面是buffers與cached的區別。
buffers是指用來給塊裝置做的緩衝大小,他只記錄檔案系統的metadata以及 tracking in-flight pages. 
cached是用來給檔案做緩衝。
那就是說:buffers是用來儲存,目錄裡面有什麼內容,許可權等等。
而cached直接用來記憶我們開啟的檔案,如果你想知道他是不是真的生效,你可以試一下,先後執行兩次命令#man X ,你就可以明顯的感覺到第二次的開打的速度快很多。
實驗:在一台沒有什麼應用的機器上做會看得比較明顯。記得實驗只能做一次,如果想多做請換一個檔案名稱。
#free
#man X
#free
#man X
#free
你可以先後比較一下free後顯示buffers的大小。
另一個實驗:
#free
#ls /dev
#free
你比較一下兩個的大小,當然這個buffers隨時都在增加,但你有ls過的話,增加的速度會變得快,這個就是buffers/chached的區別。

見:
http://www.redhat.com/advice/tips/meminfo.html
我們就當redhat的東西是比較權威的解釋吧:
引用:Buffers: Memory in buffer cache. mostly useless as metric nowadays 
Cached: Memory in the pagecache (diskcache) minus SwapCache 
SwapCache: Memory that once was swapped out, is swapped back in but still also is in the swapfile (if memory is needed it doesn't need to be swapped out AGAIN because it is already in the swapfile. This saves I/O) 

關於buffer/page cache:
http://www.linuxbyte.net/view.php?skin=art&ID=3386
引用:page cache、buffer cache和swap cache 

page cache:讀寫檔案時檔案內容的cache,大小為一個頁。不一定在磁碟上連續。 

buffer cache:讀寫磁碟塊的時候磁碟塊內容的cache,buffer cache的內容對應磁碟上一個連續的地區,一個buffer cache大小可能從512(扇區大小)到一個頁。 

swap cache: 是page cache的子集。用於多個進程共用的頁面被換出到交換區的情況。 

page cache 和 buffer cache的關係 

本質上是很不同的,buffer cache緩衝磁碟塊內容,page cache緩衝檔案的一頁內容。page cache寫回時會使用臨時的buffer cache來寫磁碟。 

bdflush: 把dirty的buffer cache寫回磁碟。通常只當dirty的buffer太多或者需要更多的buffer而記憶體開始不足時運行。page_lauder也可能喚醒它。 

kupdate: 定時運行,把寫回期限已經到了的dirty buffer寫回磁碟。 

2.4的改進:page cache和buffer cache耦合得更好了。在2.2裡,磁碟檔案的讀使用page cache,而寫繞過page cache,直接使用buffer cache,因此帶來了同步的問題:寫完之後必須使用update_vm_cache()更新可能有的page cache。2.4中page cache做了比較大的改進,檔案可以通過page cache直接寫了,page cache優先使用high memory。而且,2.4引入了新的對象:file address space,它包含用來讀寫一整頁資料的方法。這些方法考慮到了inode的更新、page cache處理和臨時buffer的使用。page cache和buffer cache的同步問題就消除了。原來使用inode+offset尋找page cache變成通過file address space+offset;原來struct page 中的inode成員被address_space類型的mapping成員取代。這個改進還使得匿名記憶體的共用成為可能(這個在2.2很難實現,許多討論過)。

可以看到核心不同buffer和cache的使用也不同,不可以單純地理解為讀寫

http://www.linuxforum.net/forum/showflat.php?Cat=&Board=linuxK&Number=106845&page=0&view=collapsed&sb=5&o=7&part=
引用:page cache是VFS的一部分,buffer cache是塊裝置驅動的一部分,或者說page cache是面向使用者IO的cache,buffer cache是面向塊裝置IO的cache,page cache按照檔案的邏輯頁進行緩衝,buffer cache按照檔案的物理塊進行緩衝。page cache與buffer cache並不相互獨立而是相互融合的,同一檔案的cache頁即可存在於page cache中,又可存在於buffer cache中,它們在實體記憶體中只有一份拷貝。檔案系統介面就處於page cache和buffer cache之間,它完成page cache的邏輯頁與buffer cache的物理塊之間的相互轉換,再交給統一的塊裝置IO進行調度處理,檔案的邏輯塊與物理塊的關係就表現為page cache與buffer cache的關係。 

2.4與2.6的不同:
http://kerneltrap.org/node/5283
引用:The main difference is that right now, there aren't two distinct caches in the kernel. Meaning, the buffer cache maps on to the page cache. Earlier, in the 2.4 series, the page cache and buffer cache used to be two separate caches, which led to problems of maintaining coherency when a block was present in the buffer cache as well as the page cache. The other issue was that you would obviously use up too much memory if a lot of blocks were present in both caches. Now that the buffer cache entries (to put it very simply) "point" to parts in the page cache, you don't have to worry much about synchronizing the two caches.

The files you can look at are mm/filemap.c, mm/page-writeback.c. It's also worth looking at mm/pdflush.c and understand how the pdflush daemon works. This'd just be a subset of everything that uses the page cache, but a decent enough place to start

 

下面轉自:http://hi.baidu.com/zheng918/blog/item/5dbe257ffae2e60029388a5b.html

最近有個月經問題,老有人問為何開機後,還沒有其他服務,mem就被用完了?是不是記憶體泄露?是否要重啟服務?只能說不要看現象,要看本質才能找到問題的根源。
往往給出這樣的結果,懷疑記憶體用了90%:
Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers
Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

這樣懷疑很普遍,因為很多人用慣了Windows。Windows下,可以使用工作管理員查看當前進程對於記憶體的消耗情況。在我看來,Windows實體記憶體總是留下一定的空間,就算此時實體記憶體有空閑時,也會讓某些程式去使用虛擬記憶體,目的是在Windows下啟動新程式時,直接分配閒置實體記憶體,這樣子新程式啟動速度就較快,而Linux則不然。

而在Linux下,使用top命令看到記憶體佔用情況:

Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers
Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

這裡的結果顯示使用了3.8G的used,佔用率達到90%。看看free的結果你還可以對比一下:
$ free -m
total used free shared buffers cached
Mem: 4049 3784 265 0 208 2939
-/+ buffers/cache: 636 3413
Swap: 2588 0 2588

雖然MEM顯示了3.7G左右的used,但是(-/+ buffers/cache)減去buffers和cache的結果可以看到,當前進程實際佔用記憶體是636M,而可用空閑(free)記憶體為3.4G。

可以這麼理解:在linux的記憶體配置機制中,優先使用實體記憶體,當實體記憶體還有空閑時(還夠用),不會釋放其佔用記憶體,就算佔用記憶體的程式已經被關閉了,該程式所佔用的記憶體用來做緩衝使用,對於開啟過的程式、或是讀取剛存取過得資料會比較快。

如上面的例子:使用了4G的記憶體,3.7G被佔用,但是buuffer和cached部分作為緩衝,可以使用命中率的方式提高使用效率,而且這部分緩衝是根據指令隨時可以釋放的,我們可以認為這部分記憶體沒有實際被使用,也可以認為它是閒置。

因此查看目前進程正在實際被使用的記憶體,是used-(buffers+cache),也可以認為如果swap沒有大量使用,mem還是夠用的,只有mem被當前進程實際佔用完(沒有了buffers和cache),才會使用到swap的。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.