?昨天的案例講了因?yàn)镻G的DOUBLE BUFFERING導(dǎo)致的SQL執(zhí)行忽快忽慢的問(wèn)題，有些朋友在問(wèn)是不是Oracle之外的很多數(shù)據(jù)庫(kù)都是用類(lèi)似的方式讀取文件，這種Double Buffering技術(shù)是不是很落后，是不是必須加以改進(jìn)。實(shí)際上，只要是使用文件系統(tǒng)，并且在讀數(shù)據(jù)時(shí)沒(méi)有采用DIO的數(shù)據(jù)庫(kù)都會(huì)存在DOUBLE BUFFERING的問(wèn)題，早期的Oracle也存在類(lèi)似問(wèn)題。

上圖比較清晰的說(shuō)明了DOUBLE BUFFERING問(wèn)題，對(duì)于寫(xiě)的情況，因?yàn)橄葘?xiě)入CACHE,再由OS把CACHE寫(xiě)入磁盤(pán)，中間會(huì)有一些性能損失，不過(guò)對(duì)于現(xiàn)代的數(shù)據(jù)庫(kù)來(lái)說(shuō)，只有REDO/WAL是需要強(qiáng)一致性寫(xiě)入的，數(shù)據(jù)文件的寫(xiě)入不會(huì)阻塞數(shù)據(jù)庫(kù)的讀寫(xiě)訪(fǎng)問(wèn)，因此這種性能損失是可以接受的。并且現(xiàn)代硬件上，IO延時(shí)已經(jīng)極大的降低了，這點(diǎn)損失也沒(méi)有太大的問(wèn)題。

對(duì)于讀操作來(lái)說(shuō)，就涉及到我們的數(shù)據(jù)庫(kù)共享緩沖池如何設(shè)計(jì)的問(wèn)題了。比較新的MySQL版本在支持DIO的操作系統(tǒng)上默認(rèn)使用DIO讀取文件，因此設(shè)置一個(gè)足夠大的innodb buffer就可以了，采用默認(rèn)的配置就不存在PG類(lèi)似Double Buffering的問(wèn)題。PG數(shù)據(jù)庫(kù)使用者對(duì)此爭(zhēng)論較多，PG官方文檔也是建議shared_buffers不用太大，給OS留下足夠的內(nèi)存用于優(yōu)化IO。

為什么PG還會(huì)堅(jiān)持這樣模式來(lái)實(shí)現(xiàn)數(shù)據(jù)庫(kù)緩沖呢？實(shí)際上維護(hù)一個(gè)極大的共享緩沖區(qū)，保持并發(fā)讀寫(xiě)性能也是十分難做好的。對(duì)于不同的應(yīng)用場(chǎng)景，緩沖的策略也會(huì)不同。如果經(jīng)常由一些大表的掃描訪(fǎng)問(wèn)，往往數(shù)據(jù)不會(huì)重復(fù)被訪(fǎng)問(wèn)，這種情況如果加載到共享緩沖中再去訪(fǎng)問(wèn)，會(huì)加大共享緩沖的閂鎖（對(duì)于PG來(lái)說(shuō)就是輕量級(jí)鎖）爭(zhēng)用，引起數(shù)據(jù)庫(kù)的性能問(wèn)題，加大熱塊沖突的延時(shí)，這樣就得不償失了。Oracle在對(duì)待此類(lèi)問(wèn)題，也采用了直接路徑讀這樣的方式來(lái)解決。

目前使用MySQL的大型數(shù)據(jù)庫(kù)比較少，即使有些MySQL庫(kù)的總?cè)萘恳策_(dá)到數(shù)個(gè)TB，但是實(shí)際上被經(jīng)常訪(fǎng)問(wèn)的數(shù)據(jù)也不過(guò)幾百M(fèi)，因此不太容易碰到共享緩沖性能帶來(lái)的總體性能問(wèn)題。而在一些比較大的PG數(shù)據(jù)庫(kù)上，并發(fā)讀寫(xiě)較高場(chǎng)景下，我們已經(jīng)遇到過(guò)不少LWLOCK帶來(lái)的性能問(wèn)題，我以前的文章中也提到過(guò)從算法上看，PG的shared buffers算法效率會(huì)略低于Oracle的DB CACHE，這些現(xiàn)象似乎也是對(duì)此的一種佐證。

在某些場(chǎng)景下，不把shared buffers設(shè)置的過(guò)大，使用OS FILE CACHE來(lái)作為輔助，也是一種優(yōu)化策略，就像前幾天討論過(guò)的數(shù)據(jù)庫(kù)可以把一些復(fù)雜的不太容易做好的事情交給OS去做。有些應(yīng)用系統(tǒng)中給shared buffer配置了絕大多數(shù)的OS內(nèi)存效果也不錯(cuò)，但是這種模式下訪(fǎng)問(wèn)冷數(shù)據(jù)的性能會(huì)打折扣。通過(guò)pgfincore這樣的工具來(lái)做預(yù)熱可以大幅度提升某些定期的分析任務(wù)對(duì)大表掃描的執(zhí)行效率。

今天不討論shared buffer配置策略的問(wèn)題，這方面我以前已經(jīng)寫(xiě)過(guò)幾篇文章探討了，有興趣的朋友可以去公眾號(hào)上搜索一下。今天我們討論一個(gè)因?yàn)閐ouble buffering機(jī)制導(dǎo)致的幾個(gè)PG指標(biāo)指示性失效的問(wèn)題。在PG的shared  buffer的不同配置策略下，有些情況下的物理讀可能并不是真正的物理讀，而是“假物理讀”，因此針對(duì)PG數(shù)據(jù)庫(kù)，共享緩沖池命中率和物理讀這兩個(gè)指標(biāo)是會(huì)存在比較嚴(yán)重的誤解的。

在Oracle數(shù)據(jù)庫(kù)中，我們會(huì)針對(duì)物理讀的突然增加產(chǎn)生一個(gè)性能告警。因?yàn)檫@可能意味著某些SQL執(zhí)行存在異常，或者IO負(fù)載突然增加，可能會(huì)引發(fā)一些不確定的數(shù)據(jù)庫(kù)性能問(wèn)題。

這個(gè)故障模型在D-SMART里也被拷貝到了PG數(shù)據(jù)庫(kù)中，但是這個(gè)故障模型的告警，在PG數(shù)據(jù)庫(kù)中可能沒(méi)有在Oracle上那么有效。因?yàn)椴煌膕hared buffers配置策略可能會(huì)導(dǎo)致某些時(shí)候產(chǎn)生的物理讀實(shí)際上并不是真正的從存儲(chǔ)設(shè)備上讀取數(shù)據(jù)，而是從FILE CACHE中讀取數(shù)據(jù)。很可能這種突發(fā)的物理讀增加并不是一個(gè)需要告警的故障，而是一種被預(yù)先設(shè)計(jì)好的正?，F(xiàn)象，如果不分青紅皂白的去告警就會(huì)不準(zhǔn)確了。作為一個(gè)通用的運(yùn)維工具產(chǎn)品，我們又無(wú)法預(yù)知用戶(hù)的應(yīng)用場(chǎng)景與設(shè)計(jì)理念，因此這個(gè)故障模型必須做改造。

數(shù)據(jù)庫(kù)緩沖命中率指標(biāo)也存在類(lèi)似問(wèn)題，某些場(chǎng)景中，數(shù)據(jù)庫(kù)緩沖命中率低有可能是PG數(shù)據(jù)庫(kù)設(shè)定好的場(chǎng)景，無(wú)需告警。我們?nèi)绻€是模仿Oracle的方式來(lái)預(yù)警則可能會(huì)產(chǎn)生大量的誤報(bào)。如果新增的“數(shù)據(jù)庫(kù)物理讀”大部分都產(chǎn)生了操作系統(tǒng)的物理讀，那么才需要進(jìn)行告警，而如果新增的“數(shù)據(jù)庫(kù)物理讀”并沒(méi)有大幅增加OS的物理IO,那么這種現(xiàn)象可能是數(shù)據(jù)庫(kù)參數(shù)配置的正?，F(xiàn)象，應(yīng)該被自動(dòng)排除。

針對(duì)數(shù)據(jù)庫(kù)緩沖區(qū)命中率的理解也是如此，當(dāng)數(shù)據(jù)庫(kù)緩沖區(qū)命中率較低的時(shí)候，我們沒(méi)有必要直接報(bào)警，而是要看操作系統(tǒng)IO總量是否大幅度增加，如果操作系統(tǒng)IO總量沒(méi)有明顯增加，那么這種數(shù)據(jù)庫(kù)緩沖命中率的下降應(yīng)該是正常的。

這兩個(gè)在Oracle中可以使用的故障模型必須進(jìn)行優(yōu)化，加入實(shí)際物理讀大幅增加的條件。但是如何描述大幅增加呢？這里就需要用到異常檢測(cè)算法了。

在D-SMART中，1000105這個(gè)指標(biāo)的含義是關(guān)鍵指標(biāo)異常，這是一個(gè)復(fù)合指標(biāo)，是針對(duì)基礎(chǔ)指標(biāo)進(jìn)行異常檢測(cè)生成的。比如30000100是操作系統(tǒng)的IOPS指標(biāo)，當(dāng)這個(gè)指標(biāo)出現(xiàn)大幅上升的時(shí)候，就意味著IO異常增長(zhǎng)。因此在那兩個(gè)故障模型中，可以加入1000105[30000100]=4這個(gè)規(guī)則，從而讓告警更為精準(zhǔn)。?