現(xiàn)象

前不久在生產(chǎn)環(huán)境上遇到的一個(gè)問(wèn)題，DBA反饋說(shuō)，入庫(kù)業(yè)務(wù)有積壓，集群的某個(gè)節(jié)點(diǎn)，ssh登錄都非?？D。

分析

由于沒(méi)有監(jiān)控，只能通過(guò)當(dāng)時(shí)的日志去推斷問(wèn)題的原因，我們?cè)谙到y(tǒng)日志里面發(fā)現(xiàn)了這個(gè)消息

sys_log.png

于此同時(shí)，數(shù)據(jù)庫(kù)的高可用發(fā)生了切換（failover），自動(dòng)切換的進(jìn)程判斷認(rèn)為主庫(kù)已經(jīng)掛了。那么大概率是某些進(jìn)程發(fā)生的IO擁堵，導(dǎo)致文件系統(tǒng)的寫緩存耗盡了OS的內(nèi)存？所以整個(gè)機(jī)器卡頓的不行，連高可用的檢活SQL都沒(méi)有響應(yīng)（所以判斷主庫(kù)掛了）。

因?yàn)镻G的shared_buffers本身是一層緩存，文件系統(tǒng)又有一層緩存，相當(dāng)于數(shù)據(jù)要雙份緩存之后，才會(huì)真正落盤。
因此我考慮是不是可以將這種寫非常重，讀不多的系統(tǒng)，把shared_buffers降到物理內(nèi)存的15%到20%，然后把這兩個(gè)內(nèi)核參數(shù)改一下

 # 更積極的去把臟數(shù)據(jù)刷盤
vm.dirty_ratio = 5
# 給大一點(diǎn)的OS緩存，讓突發(fā)的IO有更多的緩存可用，讓IO更平滑（到達(dá)60%才會(huì)強(qiáng)制同步刷盤）
vm.dirty_background_ratio = 60~80 

同時(shí)要注意下連接數(shù)和work_mem的值，保證日常連接的內(nèi)存夠用。

實(shí)際效果有待壓測(cè)驗(yàn)證一下。

補(bǔ)充

查看緩存有多少臟頁(yè)未刷盤

cat /proc/vmstat | egrep 'dirty|writeback'
nr_dirty 5563  -- 臟頁(yè)數(shù)
nr_writeback 0
nr_writeback_temp 0
nr_dirty_threshold 2625645
nr_dirty_background_threshold 656411