from: http://www.linuxfly.org/post/320/
總有很多朋友對於Linux的內存管理有疑問,之前一篇[轉]理解Linux的性能日誌似乎也沒能清除大家的疑慮。而在新版核心中,似乎對這個問題提供了新的解決方法,特轉出來給大家參考一下。最後,還附上我對這方法的意見,歡迎各位一同討論。
當在Linux下頻繁存取文件後,物理內存會很快被用光,當程序結束後,內存不會被正常釋放,而是一直作爲caching。這個問題,貌似有不少人在問,不過都沒有看到有什麼很好解決的辦法。那麼我來談談這個問題。
一、通常情況
先來說說free命令:
total used free shared buffers cached
Mem: 249 163 86 0 10 94
-/+ buffers/cache: 58 191
Swap: 511 0 511
其中:
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 ~]# 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再來試試,看看是否有釋放?
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來釋放內存。操作如下:
0
首先,/proc/sys/vm/drop_caches的值,默認爲0。
手動執行sync命令(描述:sync 命令運行 sync 子例程。如果必須停止系統,則運行sync 命令以確保文件系統的完整性。sync 命令將所有未寫的系統緩衝區寫到磁盤中,包含已修改的 i-node、已延遲的塊 I/O 和讀寫映射文件)
[root@server test]# cat /proc/sys/vm/drop_caches
3
將/proc/sys/vm/drop_caches值設爲3
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的用法在下面進行了說明
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內存管理方面的疑問,給出了一個比較“直觀”的回覆,我更覺得有點像是核心開發小組的妥協。
對於是否需要使用這個值,或向用戶提及這個值,我是有保留意見的:
2、若對於系統內存是否夠用的觀察,我還是原意去看swap的使用率和si/so兩個值的大小;
用戶常見的疑問是,爲什麼free這麼小,是否關閉應用後內存沒有釋放?
但實際上,我們都知道這是因爲Linux對內存的管理與Windows不同,free小並不是說內存不夠用了,應該看的是free的第二行最後一個值:
這纔是系統可用的內存大小。
實際項目中告訴我們,如果因爲是應用有像內存泄露、溢出的問題,從swap的使用情況是可以比較快速可以判斷的,但free上面反而比較難查看。
相反,如果在這個時候,我們告訴用戶,修改系統的一個值,“可以”釋放內存,free就大了。用戶會怎麼想?不會覺得操作系統“有問題”嗎?
所以說,我覺得既然核心是可以快速清空buffer或cache,也不難做到(這從上面的操作中可以明顯看到),但核心並沒有這樣做(默認值是0),我們就不應該隨便去改變它。
一般情況下,應用在系統上穩定運行了,free值也會保持在一個穩定值的,雖然看上去可能比較小。
當發生內存不足、應用獲取不到可用內存、OOM錯誤等問題時,還是更應該去分析應用方面的原因,如用戶量太大導致內存不足、發生應用內存溢出等情況,否則,清空buffer,強制騰出free的大小,可能只是把問題給暫時屏蔽了。
我覺得,排除內存不足的情況外,除非是在軟件開發階段,需要臨時清掉buffer,以判斷應用的內存使用情況;或應用已經不再提供支持,即使應用對內存的時候確實有問題,而且無法避免的情況下,才考慮定時清空buffer。(可惜,這樣的應用通常都是運行在老的操作系統版本上,上面的操作也解決不了)。O(∩_∩)O哈哈~