?昨天我談到第二次使用人大金倉數據庫的時候，能夠從可觀測性接口中獲得等待事件的等待時間信息，感受到了數據庫在易用性上的進步。有些朋友十分不解，不就是等待時間的長度數據采集嗎？有這么重要嗎！說實在的，運維人員獲得數據庫的等待事件的等待時長，是比重要還要重要的。

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

十多年前我和一個國產數據庫廠商交流的時候，他們就提出來他們在新版本中引入了等待事件，但是目前只能提供等待次數，無法提供等待時長。他們測試過在會話信息中加入等待時長的統計信息，但是加入后，數據庫的整體性能下降超過了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等待時長的成本開銷。