上星期感覺我們實驗室的一套OCEANBASE 4.2.1的環(huán)境突然變得特別慢，在沒有什么負載的時候連接數(shù)據(jù)庫和執(zhí)行SQL都比以前慢數(shù)倍。想去分析其原因，不過總是覺得不知道該從哪個地方開始排查，因為服務(wù)器的負載也很低，沒有任何存在瓶頸的跡象。

在搞Oracle數(shù)據(jù)庫優(yōu)化的時候，雖然分析復(fù)雜問題也挺頭痛的，不過Oracle的各種工具以及豐富的可觀測性接口總能讓人覺得分析問題有一種酣暢淋漓的感覺。本人在Oceanbase上也是一個新手，再加上在網(wǎng)上的OB運維經(jīng)驗與運維知識也不如Oracle豐富，因此對于復(fù)雜問題的分析總覺得有點力不從心。

最近一直在做D-SMART OB專版的發(fā)版前的沖刺工作，我覺得如果利用D-SMART如果無法把這個問題解決掉，就無法體現(xiàn)知識自動化的能力，因此我還是想找個時間利用工具鏈去排查一下系統(tǒng)存在問題的原因。

前天上午想給實驗室的OB加點壓，從采集一些TOP SQL來測試SQL審計的功能。啟動壓力測試后發(fā)現(xiàn)TPMC居然只有400多，往常這個腳本起碼能跑倒3-4萬。通過D-SMART簡單分析了一下，發(fā)現(xiàn)半夜2點多開始的merge還沒完，因此就簡單的把問題歸結(jié)為MERGE的問題了。中午吃完飯回來發(fā)現(xiàn)Merge結(jié)束了，不過OB集群的性能還是不好，看來我以前的猜測并不準(zhǔn)確。于是我又發(fā)起了一個Merge操作，在OCP上看到MERGE持續(xù)進行，不過依然很慢。

圖片

從D-SMART的“OB合并情況分析工具”可以看到確實有兩個任務(wù)正在進行MERGE。不過再往下分析就遇到了問題。

圖片

查看當(dāng)前merge任務(wù)明細的時候，發(fā)現(xiàn)數(shù)據(jù)是空的，找不到正在進行的Merge工作。118節(jié)點上的MERGE操作一直處于等待狀態(tài)，長時間沒有任何變化。因為手頭還有其他 事情，所以就沒有持續(xù)跟進了。昨天早上到公司發(fā)現(xiàn)那個持續(xù)時間很長的MERGE完成了，從OCP上查看，發(fā)現(xiàn)MERGE總共做了13個小時。

圖片

我也把我的問題發(fā)到了一個Oceanbase交流的群里，咨詢了一些OB的資深用戶，在他們的指導(dǎo)下我檢查了一些性能視圖，不過我看到這些視圖都是空的，還是無法定位問題。不過通過和他們的交流，我逐漸縮小了分析問題的范圍。終于把問題定位到了日志流復(fù)制不同步的問題上了。當(dāng)某個日志流不同步的時候，實際上MERGE在等待日志同步完成，因此看不到當(dāng)前Merge線程的工作內(nèi)容，但是線程還是處于run狀態(tài)。如果這個日志流日志同步了，那么在GV$OB_TABLET_COMPACTION_PROGRESS就可以看到MERGE線程在干活了。

圖片

至此，這個問題已經(jīng)能夠定位到日志流同步延時導(dǎo)致了MERGE的問題，不過實際上這個問題還是沒有解決，因為哪怕日志流同步了，Merge完成了，還是無法恢復(fù)系統(tǒng)的性能。

圖片

確實，針對這個情況如果不解決日志流追了13小時才追平的問題，應(yīng)該是無法解決當(dāng)前這個性能問題的。于是我仔細思考了整個故障的過程。因為性能問題持續(xù)存在，所以只要系統(tǒng)加壓一段時間，日志流同步的問題一直存在。經(jīng)過多次測試，我發(fā)現(xiàn)總是118節(jié)點出現(xiàn)日志流不同步的問題，其他節(jié)點并沒有出問題。這三個節(jié)點的PC SERVER配置是完全相同的，而且也并沒有哪個服務(wù)器的負載有問題。

圖片

圖片

從目前的情況看，只能繼續(xù)分析三個節(jié)點的操作系統(tǒng)有何不同了。通過D-SMART的操作系統(tǒng)診斷工具發(fā)現(xiàn)，118服務(wù)器的sys%經(jīng)常會比較高，壓測一旦開始就超過20%，其他節(jié)點都很正常。這是一個十分明顯的疑點，不過到此為止我們的工具已經(jīng)無法繼續(xù)往下提供下鉆能力，必須依托操作系統(tǒng)的工具了。在這種情況下，perf是一個十分好的分析工具，它可以提供的內(nèi)核調(diào)用情況可以很好的分析sys cpu較高的問題。

圖片

perf top命令的輸出展現(xiàn)在我面前的時候，我就恍然大悟了。acpi_pm_read，這個最近一直困擾我的系統(tǒng)調(diào)用，一下子就激活了我的大腦-這應(yīng)該是clocksource的設(shè)置問題。    

圖片

主機時鐘源日檢告警我以前是看到過的，只不過沒有和這個性能問題掛鉤而已。實際上D-SMART的日檢已經(jīng)給了我這個問題的答案，只是我沒有去關(guān)注它而已。

圖片

根據(jù)上面的分析過程，我們重新梳理了診斷工具。通過“查詢合并情況”工具進入診斷。

圖片

針對正在進行合并的作業(yè)，點擊“合并信息”可以下鉆查看當(dāng)前正在做哪些合并工作。

圖片

如果下鉆進去發(fā)現(xiàn)當(dāng)前并沒有正在進行合并的對象，那么說明當(dāng)前的合并作業(yè)正在等待什么前置條件。日志流同步是一種常見的可能原因。

圖片

點擊下鉆可以看日志流同步的情況，如果向系統(tǒng)存在性能問題的時候一樣，日志流確實處于異步狀態(tài)，那么就可以繼續(xù)下鉆去分析當(dāng)前系統(tǒng)clocksource設(shè)置的情況。

圖片

至此整個分析實現(xiàn)了一個閉環(huán)。完成工具的優(yōu)化后，整個分析過程似乎又找到了一點當(dāng)年分析Oracle故障時的流暢感覺。    

圖片

通過D-SMART內(nèi)部的一個應(yīng)用訪問性能探針指標(biāo)可以看到優(yōu)化前后十分明顯的效果。底下那根曲線是今天早上的，而那根波動十分明顯的曲線是兩天前系統(tǒng)存在問題的時段，比對時段系統(tǒng)都是沒有任何負載的。

圖片

現(xiàn)在來復(fù)盤這個問題似乎整個查找過程十分流暢，但是在實際解決這個問題的過程中是不連貫的。這種不連貫來自于兩方面的原因，一方面是因為OB的性能分析，故障診斷的知識的缺乏。當(dāng)OB數(shù)據(jù)庫出問題的時候，缺少能夠指導(dǎo)我們一點點排查問題的工作指南，甚至很多OB的性能問題，OB原廠的同學(xué)都沒有遇到過或者總結(jié)分析過，因此很多問題就變得很神秘了。

另外一方面原因是OB的等待事件的可觀測性太差了。大家可以看到上面的那個等待事件是系統(tǒng)存在性能問題時采集到的，下面的等待事件是我正在寫這篇文章時采集到的的。    

圖片

從二者我們無法看出明顯的區(qū)別，因此我們也無法通過等待事件來縮小問題分析起點時的排查范圍。Oracle數(shù)據(jù)庫的等待事件做得很優(yōu)秀，遇到系統(tǒng)問題，我們一般先看等待事件，就可以大致明確方向，縮小分析范圍，很快步入正軌。正是因為OB的等待事件還不夠完善，導(dǎo)致了其實用性遠沒有Oracle的好，因此問題分析的入口就變得更為復(fù)雜了。希望OB的同學(xué)能夠在后續(xù)的版本中加速優(yōu)化等待事件。

最后要和大家分享的就是關(guān)于時鐘源的事情，對于單機數(shù)據(jù)庫，時鐘源可能也會引起一些性能問題，不過絕對沒有分布式數(shù)據(jù)庫那么明顯。因為分布式數(shù)據(jù)庫多節(jié)點的時間協(xié)調(diào)更為頻繁。因此要確保所有的數(shù)據(jù)庫服務(wù)器、復(fù)制服務(wù)器、連接數(shù)據(jù)庫的中間件服務(wù)器等都是用相同的時鐘源的。而對于目前最常見的三種時鐘源：tsc、hpet、acpi_pm，tsc是首選，acpi_pm是最差的選擇。一般情況下，在使用分布式數(shù)據(jù)庫的時候，這些服務(wù)器的時鐘源必須都設(shè)置為tsc。    

圖片

昨天我表示要關(guān)于這個問題寫一篇文章的時候，訊飛的戴明明老師給我發(fā)來一個他們的經(jīng)驗，也是與OB的時鐘同步相關(guān)的，當(dāng)OB數(shù)據(jù)庫的服務(wù)器節(jié)點的時鐘同步存在問題的時候，在OCP中添加主機因為OCP服務(wù)器與需要添加的主機之間時鐘不同不問題，導(dǎo)致任務(wù)失敗。配置ntp統(tǒng)一時鐘后，問題才消失。當(dāng)時鐘源設(shè)置不統(tǒng)一的時候，時鐘同步問題是持續(xù)存在的，戴老師遇到的這個問題在這種情況下也會遇到。

時鐘同步問題與時鐘源問題不僅對OB是十分重要的，對于其他分布式數(shù)據(jù)庫依然重要。對于今后要使用分布式數(shù)據(jù)庫的同學(xué)，建議用小本子記下我今天分享的這個案例。