建站
咨詢
售后
建站咨詢
新聞中心
上星期感覺(jué)我們實(shí)驗(yàn)室的一套OCEANBASE 4.2.1的環(huán)境突然變得特別慢，在沒(méi)有什么負(fù)載的時(shí)候連接數(shù)據(jù)庫(kù)和執(zhí)行SQL都比以前慢數(shù)倍。想去分析其原因，不過(guò)總是覺(jué)得不知道該從哪個(gè)地方開(kāi)始排查，因?yàn)榉?wù)器的負(fù)載也很低，沒(méi)有任何存在瓶頸的跡象。
創(chuàng)新互聯(lián)-專(zhuān)業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價(jià)比門(mén)源網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式門(mén)源網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋門(mén)源地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴。
在搞Oracle數(shù)據(jù)庫(kù)優(yōu)化的時(shí)候，雖然分析復(fù)雜問(wèn)題也挺頭痛的，不過(guò)Oracle的各種工具以及豐富的可觀測(cè)性接口總能讓人覺(jué)得分析問(wèn)題有一種酣暢淋漓的感覺(jué)。本人在Oceanbase上也是一個(gè)新手，再加上在網(wǎng)上的OB運(yùn)維經(jīng)驗(yàn)與運(yùn)維知識(shí)也不如Oracle豐富，因此對(duì)于復(fù)雜問(wèn)題的分析總覺(jué)得有點(diǎn)力不從心。
最近一直在做D-SMART OB專(zhuān)版的發(fā)版前的沖刺工作，我覺(jué)得如果利用D-SMART如果無(wú)法把這個(gè)問(wèn)題解決掉，就無(wú)法體現(xiàn)知識(shí)自動(dòng)化的能力，因此我還是想找個(gè)時(shí)間利用工具鏈去排查一下系統(tǒng)存在問(wèn)題的原因。
前天上午想給實(shí)驗(yàn)室的OB加點(diǎn)壓，從采集一些TOP SQL來(lái)測(cè)試SQL審計(jì)的功能。啟動(dòng)壓力測(cè)試后發(fā)現(xiàn)TPMC居然只有400多，往常這個(gè)腳本起碼能跑倒3-4萬(wàn)。通過(guò)D-SMART簡(jiǎn)單分析了一下，發(fā)現(xiàn)半夜2點(diǎn)多開(kāi)始的merge還沒(méi)完，因此就簡(jiǎn)單的把問(wèn)題歸結(jié)為MERGE的問(wèn)題了。中午吃完飯回來(lái)發(fā)現(xiàn)Merge結(jié)束了，不過(guò)OB集群的性能還是不好，看來(lái)我以前的猜測(cè)并不準(zhǔn)確。于是我又發(fā)起了一個(gè)Merge操作，在OCP上看到MERGE持續(xù)進(jìn)行，不過(guò)依然很慢。
圖片
從D-SMART的“OB合并情況分析工具”可以看到確實(shí)有兩個(gè)任務(wù)正在進(jìn)行MERGE。不過(guò)再往下分析就遇到了問(wèn)題。
圖片
查看當(dāng)前merge任務(wù)明細(xì)的時(shí)候，發(fā)現(xiàn)數(shù)據(jù)是空的，找不到正在進(jìn)行的Merge工作。118節(jié)點(diǎn)上的MERGE操作一直處于等待狀態(tài)，長(zhǎng)時(shí)間沒(méi)有任何變化。因?yàn)槭诸^還有其他 事情，所以就沒(méi)有持續(xù)跟進(jìn)了。昨天早上到公司發(fā)現(xiàn)那個(gè)持續(xù)時(shí)間很長(zhǎng)的MERGE完成了，從OCP上查看，發(fā)現(xiàn)MERGE總共做了13個(gè)小時(shí)。
圖片
我也把我的問(wèn)題發(fā)到了一個(gè)Oceanbase交流的群里，咨詢了一些OB的資深用戶，在他們的指導(dǎo)下我檢查了一些性能視圖，不過(guò)我看到這些視圖都是空的，還是無(wú)法定位問(wèn)題。不過(guò)通過(guò)和他們的交流，我逐漸縮小了分析問(wèn)題的范圍。終于把問(wèn)題定位到了日志流復(fù)制不同步的問(wèn)題上了。當(dāng)某個(gè)日志流不同步的時(shí)候，實(shí)際上MERGE在等待日志同步完成，因此看不到當(dāng)前Merge線程的工作內(nèi)容，但是線程還是處于run狀態(tài)。如果這個(gè)日志流日志同步了，那么在GV$OB_TABLET_COMPACTION_PROGRESS就可以看到MERGE線程在干活了。
圖片
至此，這個(gè)問(wèn)題已經(jīng)能夠定位到日志流同步延時(shí)導(dǎo)致了MERGE的問(wèn)題，不過(guò)實(shí)際上這個(gè)問(wèn)題還是沒(méi)有解決，因?yàn)槟呐氯罩玖魍搅?，Merge完成了，還是無(wú)法恢復(fù)系統(tǒng)的性能。
圖片
確實(shí)，針對(duì)這個(gè)情況如果不解決日志流追了13小時(shí)才追平的問(wèn)題，應(yīng)該是無(wú)法解決當(dāng)前這個(gè)性能問(wèn)題的。于是我仔細(xì)思考了整個(gè)故障的過(guò)程。因?yàn)樾阅軉?wèn)題持續(xù)存在，所以只要系統(tǒng)加壓一段時(shí)間，日志流同步的問(wèn)題一直存在。經(jīng)過(guò)多次測(cè)試，我發(fā)現(xiàn)總是118節(jié)點(diǎn)出現(xiàn)日志流不同步的問(wèn)題，其他節(jié)點(diǎn)并沒(méi)有出問(wèn)題。這三個(gè)節(jié)點(diǎn)的PC SERVER配置是完全相同的，而且也并沒(méi)有哪個(gè)服務(wù)器的負(fù)載有問(wèn)題。
圖片
圖片
從目前的情況看，只能繼續(xù)分析三個(gè)節(jié)點(diǎn)的操作系統(tǒng)有何不同了。通過(guò)D-SMART的操作系統(tǒng)診斷工具發(fā)現(xiàn)，118服務(wù)器的sys%經(jīng)常會(huì)比較高，壓測(cè)一旦開(kāi)始就超過(guò)20%，其他節(jié)點(diǎn)都很正常。這是一個(gè)十分明顯的疑點(diǎn)，不過(guò)到此為止我們的工具已經(jīng)無(wú)法繼續(xù)往下提供下鉆能力，必須依托操作系統(tǒng)的工具了。在這種情況下，perf是一個(gè)十分好的分析工具，它可以提供的內(nèi)核調(diào)用情況可以很好的分析sys cpu較高的問(wèn)題。
圖片
perf top命令的輸出展現(xiàn)在我面前的時(shí)候，我就恍然大悟了。acpi_pm_read，這個(gè)最近一直困擾我的系統(tǒng)調(diào)用，一下子就激活了我的大腦-這應(yīng)該是clocksource的設(shè)置問(wèn)題。
圖片
主機(jī)時(shí)鐘源日檢告警我以前是看到過(guò)的，只不過(guò)沒(méi)有和這個(gè)性能問(wèn)題掛鉤而已。實(shí)際上D-SMART的日檢已經(jīng)給了我這個(gè)問(wèn)題的答案，只是我沒(méi)有去關(guān)注它而已。
圖片
根據(jù)上面的分析過(guò)程，我們重新梳理了診斷工具。通過(guò)“查詢合并情況”工具進(jìn)入診斷。
圖片
針對(duì)正在進(jìn)行合并的作業(yè)，點(diǎn)擊“合并信息”可以下鉆查看當(dāng)前正在做哪些合并工作。
圖片
如果下鉆進(jìn)去發(fā)現(xiàn)當(dāng)前并沒(méi)有正在進(jìn)行合并的對(duì)象，那么說(shuō)明當(dāng)前的合并作業(yè)正在等待什么前置條件。日志流同步是一種常見(jiàn)的可能原因。
圖片
點(diǎn)擊下鉆可以看日志流同步的情況，如果向系統(tǒng)存在性能問(wèn)題的時(shí)候一樣，日志流確實(shí)處于異步狀態(tài)，那么就可以繼續(xù)下鉆去分析當(dāng)前系統(tǒng)clocksource設(shè)置的情況。
圖片
至此整個(gè)分析實(shí)現(xiàn)了一個(gè)閉環(huán)。完成工具的優(yōu)化后，整個(gè)分析過(guò)程似乎又找到了一點(diǎn)當(dāng)年分析Oracle故障時(shí)的流暢感覺(jué)。
圖片
通過(guò)D-SMART內(nèi)部的一個(gè)應(yīng)用訪問(wèn)性能探針指標(biāo)可以看到優(yōu)化前后十分明顯的效果。底下那根曲線是今天早上的，而那根波動(dòng)十分明顯的曲線是兩天前系統(tǒng)存在問(wèn)題的時(shí)段，比對(duì)時(shí)段系統(tǒng)都是沒(méi)有任何負(fù)載的。
圖片
現(xiàn)在來(lái)復(fù)盤(pán)這個(gè)問(wèn)題似乎整個(gè)查找過(guò)程十分流暢，但是在實(shí)際解決這個(gè)問(wèn)題的過(guò)程中是不連貫的。這種不連貫來(lái)自于兩方面的原因，一方面是因?yàn)镺B的性能分析，故障診斷的知識(shí)的缺乏。當(dāng)OB數(shù)據(jù)庫(kù)出問(wèn)題的時(shí)候，缺少能夠指導(dǎo)我們一點(diǎn)點(diǎn)排查問(wèn)題的工作指南，甚至很多OB的性能問(wèn)題，OB原廠的同學(xué)都沒(méi)有遇到過(guò)或者總結(jié)分析過(guò)，因此很多問(wèn)題就變得很神秘了。
另外一方面原因是OB的等待事件的可觀測(cè)性太差了。大家可以看到上面的那個(gè)等待事件是系統(tǒng)存在性能問(wèn)題時(shí)采集到的，下面的等待事件是我正在寫(xiě)這篇文章時(shí)采集到的的。
圖片
從二者我們無(wú)法看出明顯的區(qū)別，因此我們也無(wú)法通過(guò)等待事件來(lái)縮小問(wèn)題分析起點(diǎn)時(shí)的排查范圍。Oracle數(shù)據(jù)庫(kù)的等待事件做得很優(yōu)秀，遇到系統(tǒng)問(wèn)題，我們一般先看等待事件，就可以大致明確方向，縮小分析范圍，很快步入正軌。正是因?yàn)镺B的等待事件還不夠完善，導(dǎo)致了其實(shí)用性遠(yuǎn)沒(méi)有Oracle的好，因此問(wèn)題分析的入口就變得更為復(fù)雜了。希望OB的同學(xué)能夠在后續(xù)的版本中加速優(yōu)化等待事件。
最后要和大家分享的就是關(guān)于時(shí)鐘源的事情，對(duì)于單機(jī)數(shù)據(jù)庫(kù)，時(shí)鐘源可能也會(huì)引起一些性能問(wèn)題，不過(guò)絕對(duì)沒(méi)有分布式數(shù)據(jù)庫(kù)那么明顯。因?yàn)榉植际綌?shù)據(jù)庫(kù)多節(jié)點(diǎn)的時(shí)間協(xié)調(diào)更為頻繁。因此要確保所有的數(shù)據(jù)庫(kù)服務(wù)器、復(fù)制服務(wù)器、連接數(shù)據(jù)庫(kù)的中間件服務(wù)器等都是用相同的時(shí)鐘源的。而對(duì)于目前最常見(jiàn)的三種時(shí)鐘源：tsc、hpet、acpi_pm，tsc是首選，acpi_pm是最差的選擇。一般情況下，在使用分布式數(shù)據(jù)庫(kù)的時(shí)候，這些服務(wù)器的時(shí)鐘源必須都設(shè)置為tsc。
圖片
昨天我表示要關(guān)于這個(gè)問(wèn)題寫(xiě)一篇文章的時(shí)候，訊飛的戴明明老師給我發(fā)來(lái)一個(gè)他們的經(jīng)驗(yàn)，也是與OB的時(shí)鐘同步相關(guān)的，當(dāng)OB數(shù)據(jù)庫(kù)的服務(wù)器節(jié)點(diǎn)的時(shí)鐘同步存在問(wèn)題的時(shí)候，在OCP中添加主機(jī)因?yàn)镺CP服務(wù)器與需要添加的主機(jī)之間時(shí)鐘不同不問(wèn)題，導(dǎo)致任務(wù)失敗。配置ntp統(tǒng)一時(shí)鐘后，問(wèn)題才消失。當(dāng)時(shí)鐘源設(shè)置不統(tǒng)一的時(shí)候，時(shí)鐘同步問(wèn)題是持續(xù)存在的，戴老師遇到的這個(gè)問(wèn)題在這種情況下也會(huì)遇到。
時(shí)鐘同步問(wèn)題與時(shí)鐘源問(wèn)題不僅對(duì)OB是十分重要的，對(duì)于其他分布式數(shù)據(jù)庫(kù)依然重要。對(duì)于今后要使用分布式數(shù)據(jù)庫(kù)的同學(xué)，建議用小本子記下我今天分享的這個(gè)案例。
文章名稱：從一次Oceanbase數(shù)據(jù)庫(kù)優(yōu)化談起
地址分享：http://www.dlmjj.cn/article/dphjhdd.html
