最近遇到了一個問題，
問題現象：ganglia監控主機系統響應慢，正常的命令行操作有卡頓現象，特別是打開、編輯文件時更加明顯。
問題分析：通過對ganglia監控主機的監控、top、iotop、vmstat等工具排查，發現時時刻刻都有大量磁盤寫io，本身這台服務器上還跑了生產環境的mongo及mysql的從庫等其他應用，通過iotop定位到磁盤寫io操作主要是gmond進程產生，每次采集到監控數據後會寫入到rrd文件帶來的大量寫操作。
進一步背景分析：我們采用ganglia監控生產環境系統及應用的各項指標(約15000項)，監控頻率為默認的15秒，rrds目錄大小9.3GB，磁盤為3塊2T SAS硬盤做的AID5。
這就說明每15秒都有9.3GB的磁盤寫入量(9.3*1000M/15=620MB/s)，又是機械硬盤又是RAID5又是mongodb備份庫，長時間如此系統沒掛都謝天謝地了。
遇到問題總得解決吧，經過進一步的分析：在監控指標不變的情況下，rrd文件的大小不會有明顯的變化（rrd環狀數據庫的優勢特點），即rrds目錄大小基本維持在9.3GB左右，且寫入巨大且頻繁，讀操作相對少，看來此種場景只有ssd磁盤和內存能搞定了，ssd暫時沒法換了，用內存吧（還好我的內存是16GB的，目前夠用，以後監控指標多了就得加內存了），但內存是易丟失性的，如遇服務器重啟數據就丟失了，所以就搞個crontab每10分鐘將這9.3GB的rrds同步到磁盤文件系統備份保存，監控數據雖很重要但為了系統能正常工作，減輕磁盤壓力及對其他業務的影響，10分鐘的監控數據丟失還是可以接受的，經測試9.3GB同步到磁盤文件耗時1分鐘之內，實在不行就5分鐘同步一次磁盤呗。
下面開始具體操作：
停止ganglia
/etc/init.d/gmetad stop
/etc/init.d/gmond stop
備份當前的rrds目錄
mv /var/lib/ganglia/rrds/ /var/lib/ganglia/rrds.mirror/
創建tmpfs文件系統
mount -t tmpfs -o size=14G tmpfs /mnt/ramdisk/
掛載tmpfs到ganglia的rrds目錄
mount /mnt/ramdisk /var/lib/ganglia/rrds
修改rrds目錄權限為ganglia.ganglia，ganglia需要此目錄的寫入權限
chown ganglia.ganglia /var/lib/ganglia/rrds -R
chown ganglia.ganglia /mnt/ramdisk/ -R
啟動ganglia
/etc/init.d/gmetad start
/etc/init.d/gmond start
去看看ganglia監控圖表，都正常了就ok了。
擴展1：
因內存文件系統是易失性的，特別是在斷電、系統重啟、tmpfs文件系統卸載、重掛載的時候，tmpfs文件系統的數據文件會丟失，為使這些情況下丟失的數據最少（自己平衡），設置crontab每10分鐘將ramdisk中的數據同步到磁盤文件系統做備份，我們允許10分鐘的監控數據丟失，即監控圖像會有10分鐘的中斷。
[root@min40]# crontab -l
##每10分鐘同步內存中的ganglia rrds文件到磁盤文件備份 laijingli 20151202
*/10 * * * * time rsync -av /var/lib/ganglia/rrds/ /var/lib/ganglia/rrds.mirror/ > /tmp/rsync_ganglia_rrds_to_disk.log
9.3GB約15000個rrds文件同步時間大概43秒，還可以接受
[root@min40 ]# time rsync -av /var/lib/ganglia/rrds/ /var/lib/ganglia/rrds.mirror/
real 0m42.122s
user 0m41.545s
sys 0m22.430s
擴展2：
為保證ganglia監控服務器下次重啟後監控系統正常工作，需要將將如上操作加入到開機啟動，並自動加載最新的rrds文件到ramdisk，以保證監控歷史圖像的連續性。
[root@ynadmin40]# more /etc/rc.local
###優化ganglia寫rrd文件性能，解決磁盤io問題
擴展3：
tmpfs並不適合所有應用場景，有數據丟失的風險，但對本文中的ganglia監控場景、squid緩存文件場景還是很適合的，適合自己的就是最好的。
優化前後效果對比截圖：
將ganglia的rrds目錄采用內存磁盤（tmpfs）後，優化效果還是非常明顯的(差不多有10倍的提升吧)，詳見監控截圖：
