?昨天晚上項(xiàng)目組向D-SMART研發(fā)報(bào)了一個(gè)故障案例，這個(gè)項(xiàng)目是以D-SMART為基礎(chǔ)監(jiān)控功能的常態(tài)化優(yōu)化機(jī)制的項(xiàng)目。他們發(fā)現(xiàn)了一個(gè)數(shù)據(jù)庫近期偶發(fā)性出現(xiàn)LOGON時(shí)間嚴(yán)重超長(zhǎng)的情況。經(jīng)過現(xiàn)場(chǎng)DBA的分析，發(fā)現(xiàn)是因?yàn)锳UD$長(zhǎng)期沒有清理，數(shù)據(jù)量已經(jīng)達(dá)到數(shù)千萬條導(dǎo)致的。清理AUD$后，暫時(shí)還沒有發(fā)現(xiàn)類似現(xiàn)象出現(xiàn)。

基于這個(gè)案例，他們向D-SMART項(xiàng)目組報(bào)了一個(gè)運(yùn)維經(jīng)驗(yàn)，那就是AUD$長(zhǎng)期不清理，會(huì)存在會(huì)話登錄延時(shí)加大的風(fēng)險(xiǎn)。

看到這個(gè)需求后，我第一反應(yīng)是D-SMART日檢里應(yīng)該是有AUD$的檢查項(xiàng)的，于是讓他們現(xiàn)場(chǎng)確認(rèn)一下，他們而模板里是否禁用了這個(gè)檢查項(xiàng)。經(jīng)過檢查發(fā)現(xiàn)，他們并未禁用，每天也都是有這方面的告警出現(xiàn)的，以前這個(gè)日檢告警也向甲方負(fù)責(zé)人匯報(bào)過，因?yàn)榉饩W(wǎng)，最近無法做清理操作，所以才積壓了大量的數(shù)據(jù)。

處理完這個(gè)問題，我就去干其他事情了。不過總覺得這個(gè)事情哪里有點(diǎn)不對(duì)勁。突然一想，AUD$數(shù)據(jù)量過大與LOGON超時(shí)有什么內(nèi)在的關(guān)聯(lián)呢？似乎并沒有什么直接關(guān)聯(lián)啊。因?yàn)長(zhǎng)OGON的時(shí)候僅僅是往AUD$里插入了一條數(shù)據(jù)而已，并沒有去讀取AUD$表的數(shù)據(jù)做什么分析，往一張1000條記錄的表里插入一條數(shù)據(jù)和往一張1000萬記錄的表里插入一條數(shù)據(jù)應(yīng)該不會(huì)有如此巨大的差別啊。于是我在微信里又問了現(xiàn)場(chǎng)的DBA，他怎么發(fā)現(xiàn)AUD$引發(fā)了LOGON超時(shí)這個(gè)問題的。

他說他分析了故障期間的AUD$的插入語句，244條INSERT花了128秒，而清理了AUD$后，304條花了1.25秒，效果是十分明顯的。于是我讓他查查是否存在LOGON觸發(fā)器之類的機(jī)制，或者一些特殊的審計(jì)項(xiàng)，他的反饋是沒有。

這就讓人不解了，從機(jī)理上看，AUD$表變成5GB+并不會(huì)引發(fā)插入一條記錄的性能下降100倍，從而導(dǎo)致LOGON超時(shí)。因此我相信一定是其他的原因?qū)е铝诉@個(gè)問題。于是我讓他用hola導(dǎo)出數(shù)據(jù)發(fā)給實(shí)驗(yàn)室。不巧的是，他們的版本是V2.1的，而且因?yàn)橐{管上千個(gè)運(yùn)維對(duì)象，采用而是分布式部署的模式，目前的hola 1.0.2有個(gè)BUG，無法從分布式部署的D-SMART里導(dǎo)出數(shù)據(jù)。于是我讓他把今天發(fā)生故障的兩個(gè)時(shí)點(diǎn)各生成一份“問題分析”報(bào)告，發(fā)過來。

從等待事件分析方面可以看出，排在前幾位的都是GC相關(guān)的指標(biāo)，其中也發(fā)現(xiàn)了AUD$這張表存在熱點(diǎn)。

從IO上看，IOPS/IO吞吐量都不算太高。OS方面應(yīng)該沒有太大的IO壓力。因?yàn)榭蛻裟沁叺陌踩拗疲@個(gè)系統(tǒng)的所有操作系統(tǒng)層面的指標(biāo)以及日志都沒有采集，因此我們無法分析操作系統(tǒng)IO延時(shí)是否正常。

不過從報(bào)告中可以看出，幾乎所有的數(shù)據(jù)庫寫IO指標(biāo)都超標(biāo)，而讀IO指標(biāo)沒有一個(gè)是超標(biāo)的。這就更讓人費(fèi)解了。

另外一個(gè)節(jié)點(diǎn)也出現(xiàn)了LOGON超時(shí)的現(xiàn)象，不過從問題分析報(bào)告上看，等待事件完全不同。排在前幾位的是log file sync等與IO相關(guān)的指標(biāo)。同時(shí)我們也發(fā)現(xiàn)系統(tǒng)中存在gcs log flush sync的現(xiàn)象。

從這些問題上看，AUD$寫入延時(shí)加大并不是因而更像是插入數(shù)據(jù)的性能受到了其他方面的問題的影響。于是我讓現(xiàn)場(chǎng)DBA把操作系統(tǒng)日志與數(shù)據(jù)庫日志都發(fā)過來。

在出現(xiàn)GC爭(zhēng)用的節(jié)點(diǎn)上，日志一切正常，而在出現(xiàn)Log file sync延時(shí)超時(shí)的節(jié)點(diǎn)上，我發(fā)現(xiàn)了多路徑抖動(dòng)的日志告警信息。自此，這個(gè)問題的脈絡(luò)已經(jīng)十分清晰了。因?yàn)楣?jié)點(diǎn)2上的多路徑抖動(dòng)，導(dǎo)致了IO延時(shí)的不穩(wěn)定，從而引發(fā)了AUD$插入數(shù)據(jù)的性能問題，最終導(dǎo)致了LOGON超時(shí)。

一個(gè)不經(jīng)意的發(fā)現(xiàn)，排除了一個(gè)系統(tǒng)的嚴(yán)重隱患，這套系統(tǒng)每個(gè)月月底和月初是十分繁忙的，要做大量的數(shù)據(jù)寫入和計(jì)算。幸虧問題在業(yè)務(wù)十分小的時(shí)候被發(fā)現(xiàn)了。否則月底肯定會(huì)出大問題的。而這個(gè)問題的發(fā)現(xiàn)過程也有很大的偶然成分。本來現(xiàn)場(chǎng)DBA認(rèn)為已經(jīng)解決了這個(gè)問題。要不是現(xiàn)場(chǎng)與后端的這個(gè)故障案例共享機(jī)制的存在，這個(gè)隱患很可能要到引發(fā)大問題的時(shí)候才會(huì)被發(fā)現(xiàn)。

而分析問題，大部分情況下，我們僅僅是從表象入手，問題暫時(shí)不重現(xiàn)就算搞定了。而如果分析這個(gè)問題的人缺少對(duì)數(shù)據(jù)庫機(jī)理的深入理解，是很難從這些表象中發(fā)現(xiàn)深層次的問題的。而且實(shí)際上，在運(yùn)維體系中，一線工程師也不可能放置如此高水平的DBA的。

正是因?yàn)檫@個(gè)原因，我們一直強(qiáng)調(diào)，工具不是萬能的，一線駐場(chǎng)運(yùn)維也不是萬能的。必須形成一個(gè)良好的問題閉環(huán)分析生態(tài)，讓高水平的專家、一線、二線運(yùn)維人員、高質(zhì)量的監(jiān)控?cái)?shù)據(jù)采集與分析工具相結(jié)合，形成一個(gè)完整的體系，才能夠更為高效與準(zhǔn)確的分析問題和解決問題。

而從表象與機(jī)理這個(gè)問題上，我一直強(qiáng)調(diào)問題溯源或者說根因溯源的重要性。以前與一些運(yùn)維專家討論過這個(gè)問題，一些互聯(lián)網(wǎng)企業(yè)出身的人認(rèn)為系統(tǒng)出問題，有高可用機(jī)制可以解決就行了，切掉有問題的部分組件自然就解決問題了。還有一些人認(rèn)為出問題后盡快回復(fù)運(yùn)行是關(guān)鍵，根因分析能做則做，不能做就算了，企業(yè)無法投入如此大的成本。

從某些場(chǎng)景和用戶的角度來說，這些觀點(diǎn)也都沒錯(cuò)。不過并不是所有的企業(yè)都有互聯(lián)網(wǎng)企業(yè)那么完備的高可用機(jī)制，也不是所有的系統(tǒng)都是重啟一下就能解決問題的。因此問題溯源，問題閉環(huán)對(duì)于大部分企業(yè)來說，應(yīng)該還是有價(jià)值的。目前無法全面開展的最主要問題還是成本太高，能力不足的問題。IT健康管理機(jī)制就是為了解決這種分散分析的成本問題的，通過一二三線聯(lián)動(dòng)，通過D-SMART豐富的數(shù)據(jù)采集與診斷報(bào)告，再加上最近推出的holadata數(shù)據(jù)交換工具。三線專家可以足不出戶為全國(guó)的客戶做服務(wù)，其效率提升是十分明顯的。昨天的這個(gè)問題，算上在微信群里的討論以及現(xiàn)場(chǎng)采集數(shù)據(jù)的時(shí)間，專家參與定位問題的時(shí)間也不過20分鐘而已。