現(xiàn)象
前不久在生產(chǎn)環(huán)境上遇到的一個問題拴念，DBA反饋說钧萍，入庫業(yè)務(wù)有積壓，集群的某個節(jié)點(diǎn)政鼠，ssh登錄都非撤缡荩卡頓。
分析
由于沒有監(jiān)控公般，只能通過當(dāng)時的日志去推斷問題的原因万搔，我們在系統(tǒng)日志里面發(fā)現(xiàn)了這個消息
sys_log.png
于此同時，數(shù)據(jù)庫的高可用發(fā)生了切換（failover）官帘，自動切換的進(jìn)程判斷認(rèn)為主庫已經(jīng)掛了瞬雹。那么大概率是某些進(jìn)程發(fā)生的IO擁堵，導(dǎo)致文件系統(tǒng)的寫緩存耗盡了OS的內(nèi)存刽虹？所以整個機(jī)器卡頓的不行酗捌，連高可用的檢活SQL都沒有響應(yīng)（所以判斷主庫掛了）。
因為PG的shared_buffers本身是一層緩存涌哲，文件系統(tǒng)又有一層緩存胖缤，相當(dāng)于數(shù)據(jù)要雙份緩存之后，才會真正落盤阀圾。
因此我考慮是不是可以將這種寫非常重哪廓，讀不多的系統(tǒng)，把shared_buffers降到物理內(nèi)存的15%到20%初烘，然后把這兩個內(nèi)核參數(shù)改一下
# 更積極的去把臟數(shù)據(jù)刷盤
vm.dirty_ratio = 5
# 給大一點(diǎn)的OS緩存涡真，讓突發(fā)的IO有更多的緩存可用，讓IO更平滑（到達(dá)60%才會強(qiáng)制同步刷盤）
vm.dirty_background_ratio = 60~80
同時要注意下連接數(shù)和work_mem的值肾筐，保證日常連接的內(nèi)存夠用哆料。
實(shí)際效果有待壓測驗證一下。
補(bǔ)充
查看緩存有多少臟頁未刷盤
cat /proc/vmstat | egrep 'dirty|writeback'
nr_dirty 5563 -- 臟頁數(shù)
nr_writeback 0
nr_writeback_temp 0
nr_dirty_threshold 2625645
nr_dirty_background_threshold 656411
