2017年什么準(zhǔn)備開(kāi)發(fā)D-SMART這個(gè)產(chǎn)品的時(shí)候，是受到“知識(shí)自動(dòng)化”這個(gè)理念的啟發(fā)，想通過(guò)運(yùn)維知識(shí)圖譜積累運(yùn)維經(jīng)驗(yàn)，再輔助以深度學(xué)習(xí)、人工智能的算法，實(shí)現(xiàn)復(fù)雜的數(shù)據(jù)庫(kù)運(yùn)維問(wèn)題的自動(dòng)化。一晃這件事也做了四年了，雖然說(shuō)摸到了一些門(mén)道，不過(guò)前面依然是漫漫長(zhǎng)路，和剛上路不同的是，現(xiàn)在天已經(jīng)蒙蒙亮了，不像我們剛剛出發(fā)的時(shí)候，只能看到前面黑沉沉的長(zhǎng)路。這條路已經(jīng)被證明是能走得通的，剩下來(lái)的是通過(guò)漫長(zhǎng)的積累，逐步完善知識(shí)庫(kù)。

我們的知識(shí)庫(kù)是在不斷的實(shí)踐過(guò)程中慢慢的積累，隨著從案例中提取的知識(shí)的積累不斷地彌補(bǔ)整個(gè)知識(shí)網(wǎng)絡(luò)中的缺陷，讓知識(shí)更豐富，能發(fā)揮更大的作用。因此每個(gè)案例對(duì)我們來(lái)實(shí)都是十分珍貴的，必須從中挖掘出最大的價(jià)值才行。

可能有朋友要說(shuō)了，這有什么難的，把以往的案例抽象出來(lái)，形成知識(shí)，下次再遇到類似的問(wèn)題就可以處理了，框架已經(jīng)打好了，剩下的只要積累不就行了。這實(shí)際上也是我最初的想法，不過(guò)做到今天，隨著我們不斷的拿到客戶現(xiàn)場(chǎng)的實(shí)際案例，我們發(fā)現(xiàn)實(shí)際上故障自動(dòng)化分析并不是那么簡(jiǎn)單的事情。

昨天有個(gè)客戶說(shuō)他們的系統(tǒng)中有個(gè)業(yè)務(wù)比較慢，通過(guò)TOP EVENT發(fā)現(xiàn)存在大量的latch: row cache objects等待，有個(gè)業(yè)務(wù)相關(guān)的SQL執(zhí)行的十分緩慢，要數(shù)秒鐘才能完成?？蛻裟沁吿幹眠@些問(wèn)題的經(jīng)驗(yàn)也十分豐富，很快就找到了等待這些閂鎖的語(yǔ)句都是一條類似的語(yǔ)句，因?yàn)檫@條語(yǔ)句并沒(méi)有試用綁定變量，所以每次都是硬解析。這個(gè)問(wèn)題大概率是和解析有關(guān)。從D-SMART的問(wèn)題分析報(bào)告中也能夠找到出問(wèn)題的這條SQL的情況。

在這個(gè)分析里，我們的工具做的還不夠細(xì)致，只是列出了問(wèn)題，并沒(méi)有做進(jìn)一步的根因分析，這個(gè)案例也讓我們發(fā)現(xiàn)了工具的不足。不過(guò)從這些列出的情況也可以看出解析一定是出了什么問(wèn)題。因?yàn)楫?dāng)時(shí)這個(gè)問(wèn)題已經(jīng)影響了一些交易，因此需要馬上先解決問(wèn)題。客戶那邊分析后立即采取了一個(gè)措施，將cursor_sharing設(shè)置為similar，修改參數(shù)后，問(wèn)題立即消失了，系統(tǒng)也恢復(fù)了正常。

事后我讓客戶把問(wèn)題分析報(bào)告和當(dāng)時(shí)的AWR報(bào)告發(fā)給了我，上班后，我們也會(huì)把這個(gè)案例的監(jiān)控?cái)?shù)據(jù)帶回來(lái)仔細(xì)分析分析。這種特殊的案例對(duì)于完善知識(shí)圖譜是十分關(guān)鍵的。這些年我們已經(jīng)很少發(fā)現(xiàn)因?yàn)橛步馕龆l(fā)的性能問(wèn)題了。一般來(lái)說(shuō)，以目前的PC服務(wù)器的硬件來(lái)說(shuō)，因?yàn)镃PU的核數(shù)較多，硬解析帶來(lái)的問(wèn)題已經(jīng)越來(lái)越少了，因?yàn)橐淮谓馕龅臅r(shí)間也就是幾個(gè)毫秒到幾十毫秒，強(qiáng)大的硬件資源足以支撐十分高并發(fā)的解析。不過(guò)問(wèn)題并不是那么簡(jiǎn)單的，昨天的這個(gè)案例就是一個(gè)十分珍貴的特例的案例，具有十分高的價(jià)值。

從load profile上看，系統(tǒng)負(fù)載還不算高，每秒600多的事務(wù)，12871的執(zhí)行，數(shù)量只能算是中等。不過(guò)每秒6211次的解析說(shuō)明無(wú)解析執(zhí)行的比例很低，硬解析691，占11%多一點(diǎn)，解析數(shù)量很高，但是應(yīng)該還不至于出現(xiàn)如此大的問(wèn)題的。

命中率指標(biāo)有個(gè)十分大的疑點(diǎn)，那就是非解析CPU比例僅為17.2%，反過(guò)來(lái)看，就是解析占用的CPU資源高達(dá)83%左右，這是在以往的系統(tǒng)中很少會(huì)看到的現(xiàn)象。這是一臺(tái)4路14核28線程的服務(wù)器，整個(gè)服務(wù)器有56個(gè)核，112線程，從D-SMART的報(bào)告中可以看出，CPU的使用率大概是在30%左右。

從操作系統(tǒng)層面上看，各種資源還是比較充足的，CPU的R隊(duì)列最大值也沒(méi)有超過(guò)CPU的線程數(shù)。按理說(shuō)當(dāng)前的硬件資源是足以支撐當(dāng)時(shí)的并發(fā)解析的量的。實(shí)際上當(dāng)時(shí)客戶電話里和我溝通這個(gè)問(wèn)題的時(shí)候，我也猜測(cè)了latch:row cache objects等待比較嚴(yán)重可能存在的幾種問(wèn)題，系統(tǒng)有HANG住的現(xiàn)象，SGA RESIZE，存在DDL操作，SGA設(shè)置太小等等。不過(guò)這些問(wèn)題當(dāng)時(shí)都查看過(guò)，而且也被一一排除了。

去年12月1日的歷史數(shù)據(jù)

我們實(shí)驗(yàn)室正好有這套系統(tǒng)去年的歷史數(shù)據(jù)，從歷史數(shù)據(jù)上看，硬解析數(shù)量一直很高，甚至有時(shí)候高達(dá)12000+/秒，不過(guò)用戶那邊以前并沒(méi)有發(fā)現(xiàn)其中存在什么問(wèn)題。

從TOP EVENT上看，latch:row cache objects的平均等待時(shí)間為36毫秒。似乎這個(gè)等待時(shí)間也不高，不過(guò)如果算上一個(gè)事務(wù)平均要等待10多次這個(gè)等待事件，對(duì)系統(tǒng)的影響就很大了。

平時(shí)這個(gè)等待時(shí)間的延時(shí)為0.13毫秒，偶爾會(huì)出現(xiàn)15多毫秒的點(diǎn)，不過(guò)一小時(shí)平均值36毫秒的情況還沒(méi)有出現(xiàn)過(guò)。一下子暴增200多倍，導(dǎo)致系統(tǒng)異常也就很正常了。不過(guò)latch:row cache objects的延時(shí)為什么會(huì)達(dá)到這么高?執(zhí)行數(shù)量過(guò)大，解析數(shù)量過(guò)大，硬解析過(guò)大嗎?

執(zhí)行數(shù)量上看，這個(gè)系統(tǒng)每秒的執(zhí)行數(shù)量平均值在3000-4000之間，出問(wèn)題時(shí)段一小時(shí)平均值為1.2萬(wàn)多，是平時(shí)的3倍左右。不過(guò)平時(shí)的高峰期經(jīng)常會(huì)有超過(guò)2.5萬(wàn)/秒的執(zhí)行高峰，只是沒(méi)有持續(xù)很長(zhǎng)時(shí)間而已。

硬解析也是如此，平時(shí)的平均值大約略低于300，高峰期也會(huì)出現(xiàn)高達(dá)1.2萬(wàn)+的高值，也低于出問(wèn)題時(shí)段的一小時(shí)平均值690+。

從這個(gè)案例最終通過(guò)修改cursor_sharing參數(shù)就解決了問(wèn)題的現(xiàn)象上看，確實(shí)是這條沒(méi)有試用綁定變量的SQL導(dǎo)致了問(wèn)題，不過(guò)這個(gè)問(wèn)題為什么會(huì)發(fā)生，其原因是十分復(fù)雜的。上面我們分析的持續(xù)的高峰是導(dǎo)致問(wèn)題的一個(gè)十分重要的原因之一，不過(guò)這還不是所有的原因。

仔細(xì)分析和CURSOR解析相關(guān)的指標(biāo)，我們發(fā)現(xiàn)每秒的session cache命中數(shù)量只有1700左右，和6000多的解析相比，命中率也很低，換算下來(lái)大概只有28%左右。而除了這條出問(wèn)題的SQL以外的其他解析較高的SQL語(yǔ)句的解析數(shù)量占比大約是33%，根據(jù)這個(gè)情況我們檢查了一下session_cached_cursors參數(shù)，發(fā)現(xiàn)這個(gè)參數(shù)使用了缺省的50。不過(guò)在這個(gè)案例里，加大這個(gè)參數(shù)能夠發(fā)揮的作用可能還是有限的，不過(guò)在某些其他的案例里，類似情況可能會(huì)因?yàn)檫@個(gè)參數(shù)的設(shè)置不合理而加重SQL 解析的負(fù)擔(dān)。

實(shí)際上這個(gè)看似并不復(fù)雜的案例里包含了很多復(fù)雜的內(nèi)容，只有十分深入的去分析它，才能發(fā)現(xiàn)更深層次的問(wèn)題。雖然說(shuō)當(dāng)時(shí)現(xiàn)場(chǎng)很快通過(guò)cursor_sharing解決了這個(gè)問(wèn)題，但是如果沒(méi)有把其中的問(wèn)題分析清楚，今后遇到類似的問(wèn)題，我們就無(wú)法提前預(yù)警，此類問(wèn)題稍微發(fā)生一些變化，我們就無(wú)法正確的去處置。因?yàn)榇祟悊?wèn)題的表象上十分類似，而實(shí)際上深層次的內(nèi)容上存在極大的不同。

這也是故障自動(dòng)化分析比較難做的主要原因，同樣是硬解析，為什么有的系統(tǒng)每秒數(shù)千次都不會(huì)出問(wèn)題，而這個(gè)系統(tǒng)才700就出問(wèn)題了呢?這和這臺(tái)服務(wù)器的配置、CPU使用率、SQL涉及的表的數(shù)量，是不是存在分區(qū)數(shù)量極多的分區(qū)表等等，以及和昨天這個(gè)案例類似的是否存在持續(xù)時(shí)間很長(zhǎng)的，針對(duì)同一張表的高并發(fā)解析，這些因素都有關(guān)系。如果在分析的時(shí)候要考慮到這些因素，那么我們需要更為準(zhǔn)確的采集到相關(guān)的數(shù)據(jù)，并進(jìn)行指標(biāo)化處理，并通過(guò)指標(biāo)來(lái)反映出這些問(wèn)題的因素，在分析算法中也需要覆蓋這些指標(biāo)。

這種自動(dòng)化分析能力只能在一次次的不盡如人意的分析中不斷地迭代優(yōu)化，才能獲得更為準(zhǔn)確的自動(dòng)化分析工具。就像今天我們討論的這個(gè)案例，雖然說(shuō)好像現(xiàn)在看，問(wèn)題已經(jīng)分析的差不多了，而且當(dāng)時(shí)發(fā)現(xiàn)問(wèn)題和解決問(wèn)題也很及時(shí)。不過(guò)我感覺(jué)我們還是沒(méi)有抓住問(wèn)題的最根本的那個(gè)點(diǎn)，因此我們還需要通過(guò)在用戶現(xiàn)場(chǎng)更廣泛的采集數(shù)據(jù)，從而找到更深層次的問(wèn)題原因。只有不斷地從這樣的案例中去不斷地挖掘知識(shí)，我們的知識(shí)圖譜才能變得更有價(jià)值。

本文轉(zhuǎn)載自微信公眾號(hào)「白鱔的洞穴」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系白鱔的洞穴公眾號(hào)。