從一個(gè)案例談故障模型,你學(xué)到了什么?
這是一個(gè)去年的案例,正值疫情期間,我剛剛從機(jī)場(chǎng)出來(lái),因?yàn)?8小時(shí)核酸的問(wèn)題,我被迫從上海繞道去南京。飛機(jī)落地后打開手機(jī)就看到一個(gè)網(wǎng)友給我在微信上的留言,是一個(gè)客戶的系統(tǒng)有點(diǎn)問(wèn)題。
客戶那邊反饋是系統(tǒng)有點(diǎn)慢,維保服務(wù)廠商搞不定找到他了。他上去看了看,發(fā)現(xiàn)除了活躍會(huì)話數(shù)多了一些,和平時(shí)差別并不大,做了AWR報(bào)告才發(fā)現(xiàn)似乎系統(tǒng)的IO有問(wèn)題,因?yàn)閘og file parallel write和db file parallel write都比較差,不過(guò)db file sequential read等讀IO的指標(biāo)好像還是正常的。從發(fā)來(lái)的AWR的ADDM信息看,似乎也抓不到什么有用的信息。
19C的自動(dòng)診斷也發(fā)現(xiàn)了活躍會(huì)話數(shù)的問(wèn)題,不過(guò)定位的結(jié)論不是很準(zhǔn)確,發(fā)現(xiàn)了提交與回滾較多,SGA配置問(wèn)題,會(huì)話存在短鏈接以及因?yàn)閕nvaliation導(dǎo)致的硬解析比較多這幾個(gè)問(wèn)題。
很多經(jīng)驗(yàn)不足的DBA往往會(huì)根據(jù)數(shù)據(jù)庫(kù)ADDM等自動(dòng)診斷的結(jié)論去分析問(wèn)題,而一個(gè)稍微有些經(jīng)驗(yàn)的DBA很容易從下面的Load profile中的信息就把這些問(wèn)題排除掉了。
因?yàn)槊棵?2.2個(gè)提交,0.1個(gè)rollback,1300+的執(zhí)行,5.1的硬解析,無(wú)論如何都是談不上多的,甚至每秒31M+的讀寫IO,也算不得大IO。ADDM的智能化診斷實(shí)際上只是針對(duì)time model的一個(gè)解讀,從中找出TOP n的因素而已,對(duì)于實(shí)際問(wèn)題的定位往往是不準(zhǔn)確的。
不過(guò)這個(gè)案例并不復(fù)雜,在飛機(jī)滑行的這幾分鐘里,我已經(jīng)初步定位了問(wèn)題。雖然在廊橋那里耽擱了幾分鐘,十幾分鐘后,坐上網(wǎng)約車后,我就給和朋友通了電話,把我的分析結(jié)果告訴了他。
我的初步判斷是,如果客戶存在存儲(chǔ)同步復(fù)制,那么問(wèn)題應(yīng)該出在同步復(fù)制的鏈路上了,應(yīng)該是有一條復(fù)制鏈路不穩(wěn)定,導(dǎo)致寫IO延時(shí)很大,而讀IO因?yàn)椴簧婕斑h(yuǎn)程復(fù)制鏈路的問(wèn)題,因此沒(méi)有受到影響。
實(shí)際上此類問(wèn)題如果你以前遇到過(guò),那么還是很快會(huì)找到診斷方向的,如果你沒(méi)有遇到過(guò),就比較難于定位問(wèn)題了。因?yàn)閷?duì)于此類問(wèn)題有較豐富的經(jīng)驗(yàn),因此我可以在幾分鐘內(nèi)就完成問(wèn)題的定位。這個(gè)經(jīng)驗(yàn)不僅僅是讀IO是好的,寫IO是不好的這么簡(jiǎn)單。
從TOP 10 前臺(tái)等待事件上看,日志同步,直接路徑寫,BBW,cursor: pin S wait on X等的等待事件平均延時(shí)都很高,而以往常見(jiàn)的db file sequential read等都已經(jīng)在TOP 10里消失了。這還不足以定位為存儲(chǔ)存在問(wèn)題。在如此小的負(fù)載下出現(xiàn)此類問(wèn)題,還有好幾種可能性,比如最為典型的numa導(dǎo)致的問(wèn)題,沒(méi)有使用hugepage導(dǎo)致的問(wèn)題,共享池導(dǎo)致的問(wèn)題等,都可能出現(xiàn)類似的現(xiàn)象。因此需要首先排除掉這樣的問(wèn)題,才能做出較為準(zhǔn)確的定位。
這種分析對(duì)于遇到過(guò)此類問(wèn)題的專家來(lái)說(shuō)十分簡(jiǎn)單,而對(duì)于沒(méi)有遇到過(guò)問(wèn)題的人來(lái)說(shuō),可能會(huì)一籌莫展,主要原因是里面涉及了十分復(fù)雜的邏輯。
我們首先要通過(guò)user_time和sys_time的比例關(guān)系等OS層面的情況來(lái)排除NUMA以及HUGEPAGE引起的問(wèn)題。其次要通過(guò)詳細(xì)的前臺(tái)進(jìn)程等待事件中關(guān)于共享池的事件的平均等待延時(shí)來(lái)排除共享池導(dǎo)致的問(wèn)題。
這個(gè)排除工作相對(duì)會(huì)比較麻煩,因?yàn)镮O延時(shí)的異常反過(guò)來(lái)也會(huì)影響共享池的相關(guān)指標(biāo),需要多看幾個(gè),綜合來(lái)考慮才能做出正確的判斷。
從柱狀圖中,我們可以看出db file parallel write的大多數(shù)IO都小于2ms,不過(guò)還是有3.3%的IO是異常的,而且是大于32毫秒的。
再仔細(xì)看一下就會(huì)發(fā)現(xiàn),這3.3%的IO都是大于4秒鐘延時(shí)的,如果分析到這里,存儲(chǔ)復(fù)制鏈路存在抖動(dòng)的結(jié)論成立的可能性就超過(guò)8成了。正是因?yàn)檫@個(gè)原因,我才能在幾分鐘內(nèi)做出那個(gè)判斷。和朋友通過(guò)電話40分鐘后,這個(gè)判斷被確認(rèn)了。
似乎大家看完這個(gè)案例覺(jué)得并不復(fù)雜,只要有過(guò)這樣的經(jīng)驗(yàn),下回就能夠分析這個(gè)問(wèn)題了。確實(shí)是的,遇到過(guò)類似問(wèn)題的DBA下回你遇到這個(gè)問(wèn)題的時(shí)候就多了一條診斷路徑,這就是運(yùn)維經(jīng)驗(yàn)的積累。做到這一點(diǎn)還不夠,因?yàn)閷?duì)于水平高的DBA,看了我今天的文章后,下回遇到類似問(wèn)題就可以進(jìn)行分析了。而對(duì)于大多數(shù)人來(lái)說(shuō),下回遇到此類問(wèn)題也不一定就能處理的好。這種運(yùn)維經(jīng)驗(yàn)需要固化下來(lái),形成自動(dòng)化診斷分析的模型,才能更好的積累。
說(shuō)實(shí)在的,這類十分復(fù)雜的問(wèn)題,使用深度學(xué)習(xí)構(gòu)建模型是最好的,因?yàn)檫@上千個(gè)指標(biāo)里面的復(fù)雜的關(guān)系,可能專家也不一定都能夠總結(jié)和分析的清楚。不過(guò)理論上的最好實(shí)際上不一定能夠?qū)崿F(xiàn)。此類問(wèn)題,我最近的5/6年里也不過(guò)遇到過(guò)四五次,沒(méi)有足夠的樣本,深度學(xué)習(xí)也好,人工智能也好,都無(wú)法構(gòu)建出模型出來(lái)。
此類小概率發(fā)生的問(wèn)題的知識(shí)積累還有另外一種方法,那就是依靠專家根據(jù)有限的樣本去進(jìn)行抽象分析,構(gòu)建出知識(shí)圖譜,并通過(guò)知識(shí)圖譜來(lái)勾畫出一個(gè)故障模型了。
如果我們對(duì)數(shù)據(jù)庫(kù)的內(nèi)部原理有了充分的了解后,這種抽象就變得可行了。雖然抽象出來(lái)的故障模型的精確性可能還無(wú)法一下子達(dá)到很高的水準(zhǔn),不過(guò)一個(gè)故障模型剛剛開始構(gòu)建的時(shí)候達(dá)到70-80%的準(zhǔn)確性還是可以達(dá)到的,隨著在實(shí)際生產(chǎn)環(huán)境中的磨合,通過(guò)調(diào)參或者添加關(guān)系等方式,還可以進(jìn)一步優(yōu)化模型。
這個(gè)故障模型的簡(jiǎn)圖,有興趣的朋友可以研究研究,這些因素是不是能夠定義這個(gè)故障了。這些分析,人腦去分析,也就幾分鐘就可以完成的。而要讓這個(gè)模型變成自動(dòng)化模型,還是需要繼續(xù)花點(diǎn)心思的。
在企業(yè)的運(yùn)維自動(dòng)化系統(tǒng)中,如果能夠把梳理抽象的結(jié)果變成自動(dòng)化發(fā)現(xiàn)的模型,那么下回類似問(wèn)題出現(xiàn)的時(shí)候,哪怕分析過(guò)此類問(wèn)題的專家不在現(xiàn)場(chǎng),稍微有點(diǎn)經(jīng)驗(yàn)的DBA也能夠很快發(fā)現(xiàn)問(wèn)題,并根據(jù)系統(tǒng)的提示正確地進(jìn)行問(wèn)題分析了。這種故障模型或者運(yùn)維經(jīng)驗(yàn)的積累,可以讓運(yùn)維知識(shí)真正成為企業(yè)IT部門的核心資產(chǎn)。