這幾天折騰VPS的時候發現了一個很糾結的問題。自己的內存是512MB，每次運行完一些命令後，使用free 命令查看內存使用情況，總會發現自己的內存所剩無幾。清空緩存或者reboot一下，內存又恢復如初。根據我多年使用Windows的經驗，總想着有個啥啥啥清理大師來幫我一鍵優化，瞬間內存清爽的感覺。於是找了清除緩存代碼，一運行，世界安靜了。但是那麼簡單的命令，爲啥屌爆的Linux內核自己不去調用呢？很神奇，於是找了一些資料，仔細研究了一下這個問題。
在Linux下頻繁存取文件後，物理內存會很快被用光，當程序結束後，內存不會被正常釋放，而是一直作爲caching。這個問題，貌似有不少人在問，不過都沒有看到有什麼很好解決的辦法。
介紹這個之前，先來看看free命令吧：
其中，各種參數的意義
可用的memory=free memory+buffers+cached
有了這個基礎後，可以得知，我現在used爲163MB，free爲349MB，buffer和cached分別爲10MB，94MB。
那麼我們來看看,如果我執行復制文件,內存會發生什麼變化.
在我命令執行結束後，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再來試試，看看是否有釋放？
似乎沒有任何變化。（實際情況下，內存的管理還與Swap有關）
那麼我能否手動釋放掉這些內存呢？回答是可以的！
/proc是一個虛擬文件系統，我們可以通過對它的讀寫操作做爲與kernel實體間進行通信的一種手段。也就是說可以通過修改/proc中的文件，來對當前kernel的行爲做出調整。那麼我們可以通過調整/proc/sys/vm/drop_caches來釋放內存。操作如下：
cat /proc/sys/vm/drop_caches
首先，/proc/sys/vm/drop_caches的值，默認爲0。
手動執行sync命令（描述：sync 命令運行 sync 子例程。如果必須停止系統，則運行sync 命令以確保文件系統的完整性。sync 命令將所有未寫的系統緩衝區寫到磁盤中，包含已修改的 i-node、已延遲的塊 I/O 和讀寫映射文件）
將/proc/sys/vm/drop_caches值設爲3
再來運行free命令，會發現現在的used爲66MB，free爲445MB，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。（可惜，這樣的應用通常都是運行在老的操作系統版本上，上面的操作也解決不了）。而生產環境下的服務器可以不考慮手工釋放內存，這樣會帶來更多的問題。記住內存是拿來用的,不是拿來看的。不像windows, 無論你的真實物理內存有多少,他都要拿硬盤交換文件來讀。這也就是windows爲什麼常常提示虛擬空間不足的原因，你們想想多無聊，在內存還有大部分的時候，拿出一部分硬盤空間來充當內存。硬盤怎麼會快過內存，所以我們看linux，只要不用swap的交換空間，就不用擔心自己的內存太少。如果常常swap用很多,可能你就要考慮加物理內存了，這也是linux看內存是否夠用的標準哦。
記住Linux內存是拿來用的,不是拿來看的。
內存近乎用盡時，kernel會自動釋放無用的cache，爲應用程序騰出空間，因而幾乎完全不會影響應用程序的內存使用。就像timemars說的一樣，內存空着也是空着，cache可以使用這些空餘的內存來提高系統的I/O性能。如果您的計算機頻繁進行I/O操作，drop_caches可能會導致I/O性能的下降–對某些服務器系統，可能就是非常嚴重的下降了。在free的輸出中給出的空餘內存，應該以去除cache的”-/+ buffers/cache”那一行爲準。
No related posts.