最近遇到了一個問題,
問題現象: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倍的提升吧),詳見監控截圖: