建站
咨詢
售后
建站咨詢
新聞中心
?昨天我談到第二次使用人大金倉(cāng)數(shù)據(jù)庫(kù)的時(shí)候，能夠從可觀測(cè)性接口中獲得等待事件的等待時(shí)間信息，感受到了數(shù)據(jù)庫(kù)在易用性上的進(jìn)步。有些朋友十分不解，不就是等待時(shí)間的長(zhǎng)度數(shù)據(jù)采集嗎？有這么重要嗎！說(shuō)實(shí)在的，運(yùn)維人員獲得數(shù)據(jù)庫(kù)的等待事件的等待時(shí)長(zhǎng)，是比重要還要重要的。
我們很容易從數(shù)據(jù)庫(kù)中獲得等待事件的次數(shù)，等待事件次數(shù)統(tǒng)計(jì)對(duì)于數(shù)據(jù)庫(kù)內(nèi)核來(lái)說(shuō)，實(shí)現(xiàn)起來(lái)并不麻煩，只要維護(hù)一個(gè)內(nèi)存數(shù)據(jù)結(jié)構(gòu)，通過(guò)輕量級(jí)鎖來(lái)保護(hù)這個(gè)內(nèi)存結(jié)構(gòu)就可以了。數(shù)據(jù)庫(kù)的會(huì)話可以通過(guò)向數(shù)組累計(jì)統(tǒng)計(jì)數(shù)據(jù)來(lái)獲得這些統(tǒng)計(jì)數(shù)據(jù)。甚至很多數(shù)據(jù)庫(kù)根本不需要統(tǒng)計(jì)等待次數(shù)，只需要在會(huì)話信息中增加一些等待事件的相關(guān)數(shù)據(jù)項(xiàng)就可以了。每個(gè)會(huì)話都會(huì)維護(hù)自己的會(huì)話狀態(tài)塊，每次產(chǎn)生某個(gè)等待的時(shí)候只需要對(duì)其進(jìn)行累加就可以了，其維護(hù)成本很低。但是要統(tǒng)計(jì)某個(gè)等待事件的等待時(shí)長(zhǎng)那就不同了。
十多年前我和一個(gè)國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商交流的時(shí)候，他們就提出來(lái)他們?cè)谛掳姹局幸肓说却录悄壳爸荒芴峁┑却螖?shù)，無(wú)法提供等待時(shí)長(zhǎng)。他們測(cè)試過(guò)在會(huì)話信息中加入等待時(shí)長(zhǎng)的統(tǒng)計(jì)信息，但是加入后，數(shù)據(jù)庫(kù)的整體性能下降超過(guò)了10%，想了解一下Oracle數(shù)據(jù)庫(kù)是怎么在OWI接口中實(shí)現(xiàn)等待時(shí)長(zhǎng)的統(tǒng)計(jì)的。當(dāng)時(shí)我對(duì)這個(gè)問(wèn)題研究也不深，為了回答這個(gè)問(wèn)題，我也研究了Oracle OWI接口的發(fā)展歷史。實(shí)際上Oracle對(duì)這些數(shù)據(jù)的統(tǒng)計(jì)也是經(jīng)歷過(guò)一些波折的，最初甚至通過(guò)CPU周期、resource manager等去粗略的估算時(shí)長(zhǎng)。到后來(lái)采用統(tǒng)一時(shí)間戳去做近似估算。其目的是以最低的成本，對(duì)數(shù)據(jù)庫(kù)運(yùn)行影響最小的方式較為近似的統(tǒng)計(jì)等待時(shí)長(zhǎng)。
既然獲得等待事件的時(shí)長(zhǎng)需要付出如此的代價(jià)，那么為什么DBA還是需要獲得這些數(shù)據(jù)呢？從等待事件的等待次數(shù)上不就可以知道數(shù)據(jù)庫(kù)在干什么，在等什么了嗎？實(shí)際上等待事件分析是十分復(fù)雜的事情，并不像某些DBA認(rèn)為的，看到某個(gè)等待事件，去百度上搜一搜就可以定位數(shù)據(jù)庫(kù)的問(wèn)題。某個(gè)等待事件是否引發(fā)了某個(gè)數(shù)據(jù)庫(kù)問(wèn)題，并不僅僅要看這個(gè)等待事件是否出現(xiàn)，而是要看它占總等待的比例。這個(gè)比例可以是等待次數(shù)，也可以使等待時(shí)長(zhǎng)，而等待時(shí)長(zhǎng)的準(zhǔn)確性更高。如果某個(gè)等待事件出現(xiàn)的次數(shù)很高，只能說(shuō)這方面的負(fù)載很高，如果每次等待的時(shí)長(zhǎng)都很低，或者說(shuō)和日常數(shù)據(jù)庫(kù)沒(méi)出問(wèn)題時(shí)候的平均等待時(shí)長(zhǎng)十分接近，那么可能說(shuō)明數(shù)據(jù)庫(kù)在這方面的并發(fā)性能并沒(méi)有出現(xiàn)問(wèn)題，數(shù)據(jù)庫(kù)的問(wèn)題很可能并不是因?yàn)檫@個(gè)等待事件引起的。
比如說(shuō)上圖，我們發(fā)現(xiàn)了IO延時(shí)突然增加，那么我們就可以通過(guò)突發(fā)IO延時(shí)的增加與十幾分鐘后的服務(wù)器重啟進(jìn)行綜合分析，從而把故障原因縮小到一個(gè)較為狹窄的分析面上，通過(guò)這個(gè)問(wèn)題去做下一步的問(wèn)題定位。
而如果我們只知道IO等待的次數(shù)，那么我們只能知道當(dāng)前SQL讀寫(xiě)IO的負(fù)載很高，可能有一些產(chǎn)生大IO的SQL，或者有大量的并發(fā)訪問(wèn)。但是我們無(wú)法知道當(dāng)前的IO負(fù)載是否會(huì)引發(fā)數(shù)據(jù)庫(kù)的問(wèn)題，或者說(shuō)數(shù)據(jù)庫(kù)是否存在宕機(jī)的風(fēng)險(xiǎn)。十分高興的是，我們看到目前大多數(shù)國(guó)產(chǎn)數(shù)據(jù)庫(kù)都開(kāi)始提供等待事件等待時(shí)長(zhǎng)數(shù)據(jù)了，這對(duì)于DBA運(yùn)維國(guó)產(chǎn)數(shù)據(jù)庫(kù)十分關(guān)鍵。
而采集等待事件的等待時(shí)長(zhǎng)對(duì)于數(shù)據(jù)庫(kù)核心來(lái)說(shuō)也是一個(gè)挑戰(zhàn)，用最小的成本，對(duì)數(shù)據(jù)庫(kù)性能影響最小的方式采集等待事件時(shí)長(zhǎng)十分關(guān)鍵。記得去年我在測(cè)試Polardb-O的可觀測(cè)性能力的時(shí)候，驚喜的發(fā)現(xiàn)了Polardb能夠?qū)σ恍┲攸c(diǎn)等待事件采集等待時(shí)長(zhǎng)，這些重點(diǎn)等待事件主要是lwlock和數(shù)據(jù)庫(kù)IO相關(guān)的。而對(duì)于其他的等待事件，Polardb并沒(méi)有提供等待時(shí)長(zhǎng)，這種設(shè)計(jì)也體現(xiàn)了運(yùn)維與數(shù)據(jù)庫(kù)性能之間的平衡。一般來(lái)說(shuō)，對(duì)于現(xiàn)代硬件，如果開(kāi)啟了這些采集，增加的數(shù)據(jù)庫(kù)開(kāi)銷低于5%，甚至在一些系統(tǒng)中，低于10%都是可以接受的。但是如果太高，則無(wú)法接受了。
當(dāng)時(shí)我發(fā)現(xiàn)商用版的Polardb-O中的針對(duì)IO的等待時(shí)長(zhǎng)的采集數(shù)據(jù)是空的，而開(kāi)源版的Polardb-PG中是能夠看到這些數(shù)據(jù)的。當(dāng)時(shí)我們也沒(méi)有深究這個(gè)問(wèn)題。今年我們加入了Polardb社區(qū)，同時(shí)在D-SMART中也開(kāi)始針對(duì)Polardb做深度對(duì)接，將Polardb-PG數(shù)據(jù)庫(kù)與社區(qū)版的PG數(shù)據(jù)庫(kù)獨(dú)立開(kāi)來(lái)，利用Polardb的可觀測(cè)性能力增強(qiáng)來(lái)加強(qiáng)Polardb的監(jiān)控診斷與分析能力，所以我們重新對(duì)這些可觀測(cè)性接口做了分析。通過(guò)與阿里的技術(shù)人員的溝通發(fā)現(xiàn)，要想在商用版的Polardb上采集到Polar_stat_io_latency等IO相關(guān)的等待時(shí)長(zhǎng)數(shù)據(jù)，哪怕我們使用的是本地文件系統(tǒng)的單機(jī)版，也必須將數(shù)據(jù)庫(kù)存放在Polar自帶的PFS文件系統(tǒng)上，并設(shè)置polar_enable_shared_storage_mode = on，才能采集到相關(guān)的數(shù)據(jù)。
完成這些設(shè)置后，我們就可以從polar_stat_io_info/polar_stat_io_latency視圖中看到數(shù)據(jù)了。在開(kāi)源版本中，采集IO延時(shí)的時(shí)長(zhǎng)的采集采用的是大多數(shù)數(shù)據(jù)庫(kù)使用的原生模式，在數(shù)據(jù)庫(kù)內(nèi)核中直接實(shí)現(xiàn)就可以了。但是在商用版中，這些優(yōu)化是利用云原生數(shù)據(jù)庫(kù)的特性，通過(guò)PFS底層實(shí)現(xiàn)來(lái)完成的，這樣可以大大降低數(shù)據(jù)庫(kù)內(nèi)核采集IO等待時(shí)長(zhǎng)的成本開(kāi)銷。
分享標(biāo)題：為什么平均等待時(shí)長(zhǎng)對(duì)于數(shù)據(jù)庫(kù)運(yùn)維十分關(guān)鍵
分享地址：http://m.fisionsoft.com.cn/article/cddeghi.html
