線上集群後端某台web伺服器例行檢查時，我觀察到+buffers/cache值（即linux記憶體的實際使用情況）一直都是5365左右，就算停掉nginx+fastcgi程式和其它程式也是一樣，考慮到這台機器經常在使用rsync+inotify，肯定會存在著頻繁訪問檔案的情況。而linux系統有乙個特性：在linux下頻繁訪問檔案時，就會占用物理記憶體。當程式結束時並不會自動釋放被占用的記憶體，而是一直作為cache存在。實際上核心結束乙個程式後，它是會釋放記憶體的，但是核心並沒有立刻將這部分收集到free當中，而是存在在cached或者buffer當中，提高系統的io效率，cache和buffered的記憶體是由核心進行動態的配置管理，如果系統的free大小不夠的時候，系統會自動釋放cache buffer的記憶體給程式使用（因此如果是看到used很多，來手動釋放記憶體其實是不需要的，我前面的文章及書籍其實也說明了我們應該如何觀察linux系統的實際記憶體使用情況，這裡就不再多描述了）。
操作步驟：
1、查詢當前記憶體使用情況和釋放快取的引數
free -m
命令結果如示所示：
12
3
4
total usedfreeshared buffers cached
mem: 10988 6792 4196 0 168 1001
-/+ buffers/cache: 5622 5365
swap: 4295 0 4295
檢視釋放快取引數的命令，如下所示：
1
cat/proc/sys/vm/drop_caches
系統預設顯示為0，0為預設值，即表示不釋放。
2、使用sync命令，將系統快取區中的髒資料寫入磁碟中，包括已修改的i-node、已延遲的塊i/o和讀寫對映檔案，命令如下：
1sync
3、配置檔案/proc/sys/vm/drop_caches中記錄了快取釋放的引數，命令如下：
1
echo3 >/proc/sys/vm/drop_caches
4、不重啟機器使配置改生效，命令如下：
1
sysctl -p
執行以上操作以後， +buffers/cache值由5365漲到了9500，這個值就恢復正常了。不過個人覺得linux系統（尤其是centos系統）管理記憶體的方式其實是很優異的，很多時候並不需要手動釋放記憶體；另外，工作中感覺rsync+inotify的方式還是存在著很多缺陷，正在慢慢將其往rsync+puppet環境遷移。
Centos 6 x86 64 操作記錄
shadowsocks server vimyum install vim enhanced 編譯gcc報記憶體不足的錯誤 root host update alternatives install usr bin gcc x86 64 unknown linux gnu gcc 5.4.0 usr...
centos7 x86 64搭建饑荒伺服器
在centos7下找不到 libcurl gnutls.so.4，而且必須要安裝32位的才行 yum install libcurl.i686 cd usr lib ln s libcurl.so.4 libcurl gnutls.so.4然後執行時，會因為 dst bin lib32 steamc...
CentOS6 X系統啟動流程
1.硬體啟動階段 bios自檢 bios的功能由兩部分組成，分別是post碼和runtime服務 post階段完成後它將從儲存器中被清除，而runtime服務會被一直保留，用於目標作業系統的啟動。bios兩個階段所做的詳細工作如下 步驟1 上電自檢post power on self test 主要...