手工釋放linux記憶體——/proc/sys/vm/drop_caches(轉載)

本文轉載之：http://www.cnblogs.com/lidp/archive/2009/05/31/1697946.html

 

總有很多朋友對於Linux的記憶體管理有疑問。而在新版核心中，似乎對這個問題提供了新的解決方法，特轉出來給大家參考一下。最後，還附上我對這方法的意見，歡迎各位一同討論。

當在Linux下頻繁存取檔案後，實體記憶體會很快被用光，當程式結束後，記憶體不會被正常釋放，而是一直作為caching。這個問題，貌似有不少人在問，不過都沒有看到有什麼很好解決的辦法。那麼我來談談這個問題。

一、通常情況
先來說說free命令：
引用
[root@server ~]# free -m
total used free shared buffers cached
Mem: 249 163 86 0 10 94
-/+ buffers/cache: 58 191
Swap: 511 0 511

其中：
引用
total 記憶體總數
used 已經使用的記憶體數
free 空閒的記憶體數
shared 多個程式共享的記憶體總額
buffers Buffer Cache和cached Page Cache 磁碟快取的大小
-buffers/cache 的記憶體數:used - buffers - cached
+buffers/cache 的記憶體數:free + buffers + cached

可用的memory=free memory+buffers+cached。

有了這個基礎後，可以得知，我現在used為163MB，free為86MB，buffer和cached分別為10MB，94MB。
那麼我們來看看,如果我執行復制檔案,記憶體會發生什麼變化.
引用
[root@server ~]# cp -r /etc ~/test/
[root@server ~]# free -m
total used free shared buffers cached
Mem: 249 244 4 0 8 174
-/+ buffers/cache: 62 187
Swap: 511 0 511

在我命令執行結束後，used為244MB，free為4MB，buffers為8MB，cached為174MB，天吶，都被cached吃掉了。別緊張，這是為了提高檔案讀取效率的做法。

為了提高磁碟存取效率，Linux做了一些精心的設計，除了對dentry進行快取（用於VFS，加速檔案路徑名到inode的轉換），還採取了兩種主要Cache方式：Buffer
Cache和Page
Cache。前者針對磁碟塊的讀寫，後者針對檔案inode的讀寫。這些Cache有效縮短了
I/O系統呼叫（比如read，write，getdents）的時間。

那麼有人說過段時間，linux會自動釋放掉所用的記憶體。等待一段時間後，我們使用free再來試試，看看是否有釋放？
引用
[root@server test]# free -m
total used free shared buffers cached
Mem: 249 244 5 0 8 174
-/+ buffers/cache: 61 188
Swap: 511 0 511

似乎沒有任何變化。（實際情況下，記憶體的管理還與Swap有關）

那麼我能否手動釋放掉這些記憶體呢？回答是可以的！

二、手動釋放快取
/proc是一個虛擬檔案系統，我們可以通過對它的讀寫操作做為與kernel實體間進行通訊的一種手段。也就是說可以通過修改/proc中的檔案，來對當前kernel的行為做出調整。那麼我們可以通過調整/proc/sys/vm/drop_caches來釋放記憶體。操作如下：
引用
[root@server test]# cat /proc/sys/vm/drop_caches
0

首先，/proc/sys/vm/drop_caches的值，預設為0。
引用
[root@server test]# sync

手動執行sync命令（描述：sync 命令執行 sync
子例程。如果必須停止系統，則執行sync 命令以確保檔案系統的完整性。sync
命令將所有未寫的系統緩衝區寫到磁碟中，包含已修改的 i-node、已延遲的塊 I/O
和讀寫對映檔案）
引用
[root@server test]# echo 3 > /proc/sys/vm/drop_caches
[root@server test]# cat /proc/sys/vm/drop_caches
3

將/proc/sys/vm/drop_caches值設為3
引用
[root@server test]# free -m
total used free shared buffers cached
Mem: 249 66 182 0 0 11
-/+ buffers/cache: 55 194
Swap: 511 0 511

再來執行free命令，會發現現在的used為66MB，free為182MB，buffers為0MB，cached為11MB。那麼有效的釋放了buffer和cache。

◎ 有關/proc/sys/vm/drop_caches的用法在下面進行了說明
引用
/proc/sys/vm/drop_caches (since Linux 2.6.16)
Writing to this file causes the kernel to drop clean caches,
dentries and inodes from memory, causing that memory to become
free.

To free pagecache, use echo 1 > /proc/sys/vm/drop_caches; to
free dentries and inodes, use echo 2 > /proc/sys/vm/drop_caches;
to free pagecache, dentries and inodes, use echo 3 >
/proc/sys/vm/drop_caches.

Because this is a non-destructive operation and dirty objects
are not freeable, the user should run sync first.

三、我的意見
上述文章就長期以來很多使用者對Linux記憶體管理方面的疑問，給出了一個比較"直觀"的回覆，我更覺得有點像是核心開發小組的妥協。
對於是否需要使用這個值，或向使用者提及這個值，我是有保留意見的：
引用
1、從man可以看到，這值從2.6.16以後的核心版本才提供，也就是老版的作業系統，如紅旗DC
5.0、RHEL 4.x之前的版本都沒有；
2、若對於系統記憶體是否夠用的觀察，我還是原意去看swap的使用率和si/so兩個值的大小；

使用者常見的疑問是，為什麼free這麼小，是否關閉應用後記憶體沒有釋放？
但實際上，我們都知道這是因為Linux對記憶體的管理與Windows不同，free小並不是說記憶體不夠用了，應該看的是free的第二行最後一個值：
引用
-/+ buffers/cache: 58 191

這才是系統可用的記憶體大小。
實際專案中告訴我們，如果因為是應用有像記憶體洩露、溢位的問題，從swap的使用情況是可以比較快速可以判斷的，但free上面反而比較難檢視。
相反，如果在這個時候，我們告訴使用者，修改系統的一個值，"可以"釋放記憶體，free就大了。使用者會怎麼想？不會覺得作業系統"有問題"嗎？
所以說，我覺得既然核心是可以快速清空buffer或cache，也不難做到（這從上面的操作中可以明顯看到），但核心並沒有這樣做（預設值是0），我們就不應該隨便去改變它。
一般情況下，應用在系統上穩定執行了，free值也會保持在一個穩定值的，雖然看上去可能比較小。
當發生記憶體不足、應用獲取不到可用記憶體、OOM錯誤等問題時，還是更應該去分析應用方面的原因，如使用者量太大導致記憶體不足、發生應用記憶體溢位等情況，否則，清空buffer，強制騰出free的大小，可能只是把問題給暫時遮蔽了。

我覺得，排除記憶體不足的情況外，除非是在軟體開發階段，需要臨時清掉buffer，以判斷應用的記憶體使用情況；或應用已經不再提供支援，即使應用對記憶體的時候確實有問題，而且無法避免的情況下，才考慮定時清空buffer。（可惜，這樣的應用通常都是執行在老的作業系統版本上，上面的操作也解決不了）。O(∩_∩)O哈哈~
visitor
2009/02/25 11:28
完全沒必要這樣做，即使記憶體全被cache滿了，執行一個大程式試試，絕不會有什麼"記憶體不足"的情況，需要多少記憶體就從cache釋放多少記憶體。

cache的好處可以減少很多硬碟訪問，我的一塊老硬碟，用windows的時候每開啟一個程式硬碟都要狂響一陣，和拖拉機有一比，但用linux的時候硬碟非常安靜！
linuxing 回覆於 2009/02/26 00:06
O(∩_∩)O哈哈~，可惜並不是每個人都明白linux這個問題，正如我最後說的："我更覺得有點像是核心開發小組的妥協"。
但轉這個帖子出來，也不是沒有實際意義的。

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