【轉】Linux手動釋放快取的方法
轉自：https://www.cnblogs.com/focai/p/5829897.html
Linux釋放記憶體的命令：
sync
echo 1 > /proc/sys/vm/drop_caches
drop_caches的值可以是0-3之間的數字，代表不同的含義：
0：不釋放（系統預設值）
1：釋放頁快取
2：釋放dentries和inodes
3：釋放所有快取
釋放完記憶體後改回去讓系統重新自動分配記憶體。
echo 0 >/proc/sys/vm/drop_caches
free -m #看記憶體是否已經釋放掉了。
如果我們需要釋放所有快取，就輸入下面的命令：
echo 3 > /proc/sys/vm/drop_caches
######### Linux釋放記憶體的相關知識 ###############
在Linux系統下，我們一般不需要去釋放記憶體，因為系統已經將記憶體管理的很好。但是凡事也有例外，有的時候記憶體會被快取佔用掉，導致系統使用SWAP空 間影響效能，例如當你在linux下頻繁存取檔案後,實體記憶體會很快被用光,當程式結束後,記憶體不會被正常釋放,而是一直作為caching。，此時就需 要執行釋放記憶體（清理快取）的操作了。
Linux系統的快取機制是相當先進的，他會針對dentry（用於VFS，加速檔案路徑名到inode的轉換）、Buffer Cache（針對磁碟塊的讀寫）和Page Cache（針對檔案inode的讀寫）進行快取操作。但是在進行了大量檔案操作之後，快取會把記憶體資源基本用光。但實際上我們檔案操作已經完成，這部分 快取已經用不到了。這個時候，我們難道只能眼睜睜的看著快取把記憶體空間佔據掉嗎？所以，我們還是有必要來手動進行Linux下釋放記憶體的操作，其實也就是 釋放快取的操作了。/proc是一個虛擬檔案系統,我們可以通過對它的讀寫操作做為與kernel實體間進行通訊的一種手段.也就是說可以通過修改 /proc中的檔案,來對當前kernel的行為做出調整.那麼我們可以通過調整/proc/sys/vm/drop_caches來釋放記憶體。要達到釋 放快取的目的，我們首先需要了解下關鍵的配置檔案/proc/sys/vm/drop_caches。這個檔案中記錄了快取釋放的引數，預設值為0，也就 是不釋放快取。
一般複製了檔案後,可用記憶體會變少，都被cached佔用了，這是linux為了提高檔案讀取效率的做法：為了提高磁碟存取效率, Linux做了一些精心的設計, 除了對dentry進行快取(用於VFS,加速檔案路徑名到inode的轉換), 還採取了兩種主要Cache方式：Buffer Cache和Page Cache。前者針對磁碟塊的讀寫，後者針對檔案inode的讀寫。這些Cache有效縮短了 I/O系統呼叫(比如read,write,getdents)的時間。"
釋放記憶體前先使用sync命令做同步，以確保檔案系統的完整性，將所有未寫的系統緩衝區寫到磁碟中，包含已修改的 i-node、已延遲的塊 I/O 和讀寫對映檔案。否則在釋放快取的過程中，可能會丟失未儲存的檔案。
[
total used free shared buffers cached
Mem: 7979 7897 82 0 30 3918
-/ buffers/cache: 3948 4031
Swap: 4996 438 4558
第一行用全域性角度描述系統使用的記憶體狀況：
total 記憶體總數
used 已經使用的記憶體數，一般情況這個值會比較大，因為這個值包括了cache 應用程式使用的記憶體
free 空閒的記憶體數
shared 多個程序共享的記憶體總額
buffers 快取，主要用於目錄方面,inode值等（ls大目錄可看到這個值增加）
cached 快取，用於已開啟的檔案
第二行描述應用程式的記憶體使用：
-buffers/cache 的記憶體數:used - buffers - cached
buffers/cache 的記憶體數:free buffers cached
前個值表示-buffers/cache 應用程式使用的記憶體大小，used減去快取值
後個值表示 buffers/cache 所有可供應用程式使用的記憶體大小，free加上快取值
第三行表示swap的使用：
used 已使用
free 未使用
可用的記憶體=free memory buffers cached。
為什麼free這麼小，是否關閉應用後記憶體沒有釋放？
但實際上，我們都知道這是因為Linux對記憶體的管理與Windows不同，free小並不是說記憶體不夠用了，應該看的是free的第二行最後一個值：-/ buffers/cache: 3948 4031 ，這才是系統可用的記憶體大小。
實際專案中的經驗告訴我們，如果因為是應用有像記憶體洩露、溢位的問題，從swap的使用情況是可以比較快速可以判斷的，但free上面反而比較難檢視。我覺得既然核心是可以快速清空buffer或cache，但核心並沒有這樣做（預設值是0），我們不應該隨便去改變它。
一般情況下，應用在系統上穩定運行了，free值也會保持在一個穩定值的，雖然看上去可能比較小。當發生記憶體不足、應用獲取不到可用記憶體、OOM錯 誤等問題時，還是更應該去分析應用方面的原因，如使用者量太大導致記憶體不足、發生應用記憶體溢位等情況，否則，清空buffer，強制騰出free的大小，可 能只是把問題給暫時遮蔽了，所以說一般情況下linux都不用經常手動釋放記憶體。