為什麼平均等待時長對於資料庫運維十分關鍵

昨天我談到第二次使用人大金倉資料庫的時候，能夠從可觀測性介面中獲得等待事件的等待時間資訊，感受到了資料庫在易用性上的進步。有些朋友十分不解，不就是等待時間的長度資料採集嗎?有這麼重要嗎!說實在的，運維人員獲得資料庫的等待事件的等待時長，是比重要還要重要的。

我們很容易從資料庫中獲得等待事件的次數，等待事件次數統計對於資料庫核心來說，實現起來並不麻煩，只要維護一個記憶體資料結構，透過輕量級鎖來保護這個記憶體結構就可以了。資料庫的會話可以透過向陣列累計統計資料來獲得這些統計資料。甚至很多資料庫根本不需要統計等待次數，只需要在會話資訊中增加一些等待事件的相關資料項就可以了。每個會話都會維護自己的會話狀態塊，每次產生某個等待的時候只需要對其進行累加就可以了，其維護成本很低。但是要統計某個等待事件的等待時長那就不同了。

十多年前我和一個國產資料庫廠商交流的時候，他們就提出來他們在新版本中引入了等待事件，但是目前只能提供等待次數，無法提供等待時長。他們測試過在會話資訊中加入等待時長的統計資訊，但是加入後，資料庫的整體效能下降超過了10%，想了解一下Oracle資料庫是怎麼在OWI介面中實現等待時長的統計的。當時我對這個問題研究也不深，為了回答這個問題，我也研究了Oracle OWI介面的發展歷史。實際上Oracle對這些資料的統計也是經歷過一些波折的，最初甚至透過CPU週期、resource manager等去粗略的估算時長。到後來採用統一時間戳去做近似估算。其目的是以最低的成本，對資料庫執行影響最小的方式較為近似的統計等待時長。

既然獲得等待事件的時長需要付出如此的代價，那麼為什麼DBA還是需要獲得這些資料呢?從等待事件的等待次數上不就可以知道資料庫在幹什麼，在等什麼了嗎?實際上等待事件分析是十分複雜的事情，並不像某些DBA認為的，看到某個等待事件，去百度上搜一搜就可以定位資料庫的問題。某個等待事件是否引發了某個資料庫問題，並不僅僅要看這個等待事件是否出現，而是要看它佔總等待的比例。這個比例可以是等待次數，也可以使等待時長，而等待時長的準確性更高。如果某個等待事件出現的次數很高，只能說這方面的負載很高，如果每次等待的時長都很低，或者說和日常資料庫沒出問題時候的平均等待時長十分接近，那麼可能說明資料庫在這方面的併發效能並沒有出現問題，資料庫的問題很可能並不是因為這個等待事件引起的。

比如說上圖，我們發現了IO延時突然增加，那麼我們就可以透過突發IO延時的增加與十幾分鍾後的伺服器重啟進行綜合分析，從而把故障原因縮小到一個較為狹窄的分析面上，透過這個問題去做下一步的問題定位。

而如果我們只知道IO等待的次數，那麼我們只能知道當前SQL讀寫IO的負載很高，可能有一些產生大IO的SQL，或者有大量的併發訪問。但是我們無法知道當前的IO負載是否會引發資料庫的問題，或者說資料庫是否存在當機的風險。十分高興的是，我們看到目前大多數國產資料庫都開始提供等待事件等待時長資料了，這對於DBA運維國產資料庫十分關鍵。

而採集等待事件的等待時長對於資料庫核心來說也是一個挑戰，用最小的成本，對資料庫效能影響最小的方式採集等待事件時長十分關鍵。記得去年我在測試Polardb-O的可觀測效能力的時候，驚喜的發現了Polardb能夠對一些重點等待事件採集等待時長，這些重點等待事件主要是lwlock和資料庫IO相關的。而對於其他的等待事件，Polardb並沒有提供等待時長，這種設計也體現了運維與資料庫效能之間的平衡。一般來說，對於現代硬體，如果開啟了這些採集，增加的資料庫開銷低於5%，甚至在一些系統中，低於10%都是可以接受的。但是如果太高，則無法接受了。

當時我發現商用版的Polardb-O中的針對IO的等待時長的採集資料是空的，而開源版的Polardb-PG中是能夠看到這些資料的。當時我們也沒有深究這個問題。今年我們加入了Polardb社群，同時在D-SMART中也開始針對Polardb做深度對接，將Polardb-PG資料庫與社群版的PG資料庫獨立開來，利用Polardb的可觀測效能力增強來加強Polardb的監控診斷與分析能力，所以我們重新對這些可觀測性介面做了分析。透過與阿里的技術人員的溝通發現，要想在商用版的Polardb上採集到Polar_stat_io_latency等IO相關的等待時長資料，哪怕我們使用的是本地檔案系統的單機版，也必須將資料庫存放在Polar自帶的PFS檔案系統上，並設定polar_enable_shared_storage_mode = on，才能採集到相關的資料。

完成這些設定後，我們就可以從polar_stat_io_info/polar_stat_io_latency檢視中看到資料了。在開源版本中，採集IO延時的時長的採集採用的是大多數資料庫使用的原生模式，在資料庫核心中直接實現就可以了。但是在商用版中，這些最佳化是利用雲原生資料庫的特性，透過PFS底層實現來完成的，這樣可以大大降低資料庫核心採集IO等待時長的成本開銷。