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

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

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

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

圖片

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

圖片

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

圖片

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

圖片

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

圖片

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

圖片

圖片

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

圖片

perf top命令的輸出展現在我面前的時候，我就恍然大悟了。acpi_pm_read，這個最近一直困擾我的系統調用，一下子就激活了我的大腦-這應該是clocksource的設置問題。    

圖片

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

圖片

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

圖片

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

圖片

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

圖片

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

圖片

至此整個分析實現了一個閉環。完成工具的優化后，整個分析過程似乎又找到了一點當年分析Oracle故障時的流暢感覺。    

圖片

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

圖片

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

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

圖片

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

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

圖片

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

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