建站
咨詢
售后
建站咨詢
新聞中心
DBA行業(yè)的老司機(jī)知道等待事件分析對數(shù)據(jù)庫運維來說有多么重要，等待事件分析是Oracle在7.3版本中推出OWI后才變得可能的，必須在數(shù)據(jù)庫核心層提供接口才能實現(xiàn)。
翠屏網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),翠屏網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為翠屏1000多家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營銷網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的翠屏做網(wǎng)站的公司定做！
國產(chǎn)數(shù)據(jù)庫在等待事件接口方面也做了很多的工作，我第一次用達(dá)夢數(shù)據(jù)庫的時候就發(fā)現(xiàn)居然有等待事件，雖然達(dá)夢數(shù)據(jù)庫的等待事件還比較簡單，不過對于運維來說還是很有價值的。最近和Oceanbase、Polardb的朋友交流中也發(fā)現(xiàn)他們也在等待事件分析方面做很多突破性的功能增強(qiáng)，一些能力可能很快就可以合并到主線版本中了。
PostgreSQL是在9.6版本首先引入等待事件的，雖然openGauss的基礎(chǔ)PostgreSQL版本(9.2.4)并不支持等待事件，不過openGauss從1.0開始就支持等待事件了，當(dāng)然2.0之后openGauss的等待事件有了極大的提升，支持了等待時間。對于等待事件分析來說，支持等待時間分析是一個巨大的提升，這可以讓等待事件分析更為有效。
openGauss的等待事件并沒有放在pg_stat_activity中，而是另外使用了一個視圖接口。這種設(shè)計我猜想是為了避免對PG內(nèi)核做過多的修改，從而影響PG核心的穩(wěn)定性。因為等待事件采集和會話的活動有直接的關(guān)系，涉及到數(shù)據(jù)庫最核心的代碼。openGauss通過兩張表分別來實現(xiàn)等待事件分析。
一張是thread_wat_status,另外一張是等待事件匯總信息wait_events，記錄了數(shù)據(jù)庫啟動以來每個等待事件發(fā)生的次數(shù)、平均等待時間，最大等待時間，最小等待時間等信息。這張視圖有點類似Oracle的v$eventmetric。
比較Oracle(上圖是11g)的這張視圖，openGauss提供了一些類似信息最大值，最小值，平均值的數(shù)據(jù)，只是有經(jīng)驗的DBA都知道全局的最大值最小值是沒有意義的，數(shù)據(jù)庫啟動后只要出現(xiàn)過一次極端現(xiàn)象，就會把這些值固化了，反而對于運維來說沒有價值了。
看樣子這個功能模塊的產(chǎn)品經(jīng)理運維實戰(zhàn)的經(jīng)驗還略顯不足，實際上如果能夠保存最近1分鐘，最近5分鐘，最近10分鐘，最近半小時這些最大最小值，或者僅僅保存最近1分鐘的最大/最小值對于運維來說更有價值。不管如何，這種設(shè)計體現(xiàn)了openGauss數(shù)據(jù)庫產(chǎn)品的開發(fā)者是考慮了運維的需求的。
上面是openGauss 2.1的等待事件數(shù)量-321個，比PG 12足足多了一倍，openGauss 3.0的數(shù)量差不太多。
總數(shù)是353，多了30多個，每個版本等待事件數(shù)量都在增加，說明這個接口的活躍度是可以的，如此發(fā)展下去，這個功能會越來越完善。
不過比起Oracle 11g的1367還是有差距，Oracle 19c，這個數(shù)量贏又快翻了一倍了。國貨還是有很大的發(fā)展余地。不過看等待事件，不僅僅要看數(shù)量，而是要看是不是都是一些有效的等待事件。我們在openGauss3上做了幾次小的benchmark壓測(我們的環(huán)境只是功能測試環(huán)境，一臺虛擬機(jī)上部署了多套數(shù)據(jù)庫，因此只能做一些小壓測)，大概平均TPMC為2500左右。然后來看看有哪些等待事件是非零的。
相當(dāng)不錯了，有66個等待事件的等待次數(shù)是非零的。類似的情況，在Oracle 11g里，大約也只有100多個等待事件是非零的，因為很多等待事件是某些場景下才會發(fā)生的。
從這個查詢中我們可以看到等待事件排序比較靠前的基本上都是和IO相關(guān)的。具體某個等待事件的含義我們后面再慢慢研究，我們也會在PG知識圖譜的基礎(chǔ)上構(gòu)建支持openGaus等待事件分析的知識圖譜。
接下來我們先來看幾個openGauss 等待事件性能視圖的考慮的比較好的地方。除了剛才說的并均值之類的，還有就是failed_wait字段和last_updated。正常的系統(tǒng)中一般不會出現(xiàn)failed wait，如果某個時間段里出現(xiàn)了較多的failed wait,說明這個等待存在較大的問題。而last_updated則記錄了該等待事件最后一次等待的時間，這在運維中遇到了性能問題，需要分析根因的時候十分重要，有可能這個時間戳就可以幫你過濾掉一些重要的等待事件，從而幫你更精準(zhǔn)的定位問題。
說完優(yōu)點，我們就要說說缺點了，Oracle在v$event_histogram中保留了非零等待事件的直方圖數(shù)據(jù)。
這個數(shù)據(jù)對于做深度的分析十分有價值。通過定期采集數(shù)據(jù)，可以了解很多等待事件的詳情。
我們再回過頭來看看Oracle的v$eventmetric視圖，通過begin_time/end_time我們會發(fā)現(xiàn)，對于大多數(shù)EVENT，oracle記錄的都是1分鐘的采樣周期內(nèi)的情況。WAIT EVENT是一種瞬間發(fā)生的等待，在具體的性能分析工作中，長時間的累計值實際上并不重要，更為重要的是最近的情況，而1分鐘的統(tǒng)計值十分有助于幫助DBA進(jìn)行分析。哪怕存在一些特殊的異常值，通過觀察幾次一分鐘的數(shù)值，就可以基本了解某個等待事件在此期間的異常情況。
Oracle的v$sysstat中記錄的是一些系統(tǒng)統(tǒng)計數(shù)據(jù)，這些數(shù)據(jù)記錄一個統(tǒng)計值就夠用了，我們可以通過多個SNAP的差異來進(jìn)行分析。如果我們沒有采集歷史的SNAP，那么分析歷史數(shù)據(jù)還是有些困難的。不過這些指標(biāo)在AWR中都有采集。而對于等待事件這種分析，和統(tǒng)計數(shù)據(jù)的分析需求是不同的。因此簡單的記錄統(tǒng)計值是不夠的，openGauss的研發(fā)人員也發(fā)現(xiàn)了這方面的問題，因此增加了一些平均值之類的屬性。不過個人以多年的運維經(jīng)驗來看，還是更喜歡使用Oracle的這種模式。有可能是我已經(jīng)在多年的Oracle數(shù)據(jù)庫運維中被洗腦了，不過似乎Oracle的方式在現(xiàn)場分析時效果更好。我們的國產(chǎn)數(shù)據(jù)庫企業(yè)還是需要多學(xué)習(xí)學(xué)習(xí)Oracle在一些細(xì)節(jié)上的處理的。這些細(xì)節(jié)都是多年數(shù)據(jù)庫產(chǎn)品發(fā)展中積累下來的，技術(shù)含量并不一定很高，但是實戰(zhàn)效果確實很好。
最后我們再來看看thread_wait_status，令人略感遺憾的是在會話級的等待事件上并沒有包含等待時間，我想以后的版本應(yīng)該會慢慢的加上，能做系統(tǒng)級的等待事件分析已經(jīng)為具有細(xì)粒度等待事件分析的能力提供了一個基礎(chǔ)。
網(wǎng)頁題目：分析一下OpenGauss的等待事件
本文地址：http://fisionsoft.com.cn/article/cdeocej.html
