?昨天的案例講了因為PG的DOUBLE BUFFERING導致的SQL執行忽快忽慢的問題，有些朋友在問是不是Oracle之外的很多數據庫都是用類似的方式讀取文件，這種Double Buffering技術是不是很落后，是不是必須加以改進。實際上，只要是使用文件系統，并且在讀數據時沒有采用DIO的數據庫都會存在DOUBLE BUFFERING的問題，早期的Oracle也存在類似問題。

上圖比較清晰的說明了DOUBLE BUFFERING問題，對于寫的情況，因為先寫入CACHE,再由OS把CACHE寫入磁盤，中間會有一些性能損失，不過對于現代的數據庫來說，只有REDO/WAL是需要強一致性寫入的，數據文件的寫入不會阻塞數據庫的讀寫訪問，因此這種性能損失是可以接受的。并且現代硬件上，IO延時已經極大的降低了，這點損失也沒有太大的問題。

對于讀操作來說，就涉及到我們的數據庫共享緩沖池如何設計的問題了。比較新的MySQL版本在支持DIO的操作系統上默認使用DIO讀取文件，因此設置一個足夠大的innodb buffer就可以了，采用默認的配置就不存在PG類似Double Buffering的問題。PG數據庫使用者對此爭論較多，PG官方文檔也是建議shared_buffers不用太大，給OS留下足夠的內存用于優化IO。

為什么PG還會堅持這樣模式來實現數據庫緩沖呢？實際上維護一個極大的共享緩沖區，保持并發讀寫性能也是十分難做好的。對于不同的應用場景，緩沖的策略也會不同。如果經常由一些大表的掃描訪問，往往數據不會重復被訪問，這種情況如果加載到共享緩沖中再去訪問，會加大共享緩沖的閂鎖（對于PG來說就是輕量級鎖）爭用，引起數據庫的性能問題，加大熱塊沖突的延時，這樣就得不償失了。Oracle在對待此類問題，也采用了直接路徑讀這樣的方式來解決。

目前使用MySQL的大型數據庫比較少，即使有些MySQL庫的總容量也達到數個TB，但是實際上被經常訪問的數據也不過幾百M，因此不太容易碰到共享緩沖性能帶來的總體性能問題。而在一些比較大的PG數據庫上，并發讀寫較高場景下，我們已經遇到過不少LWLOCK帶來的性能問題，我以前的文章中也提到過從算法上看，PG的shared buffers算法效率會略低于Oracle的DB CACHE，這些現象似乎也是對此的一種佐證。

在某些場景下，不把shared buffers設置的過大，使用OS FILE CACHE來作為輔助，也是一種優化策略，就像前幾天討論過的數據庫可以把一些復雜的不太容易做好的事情交給OS去做。有些應用系統中給shared buffer配置了絕大多數的OS內存效果也不錯，但是這種模式下訪問冷數據的性能會打折扣。通過pgfincore這樣的工具來做預熱可以大幅度提升某些定期的分析任務對大表掃描的執行效率。

今天不討論shared buffer配置策略的問題，這方面我以前已經寫過幾篇文章探討了，有興趣的朋友可以去公眾號上搜索一下。今天我們討論一個因為double buffering機制導致的幾個PG指標指示性失效的問題。在PG的shared  buffer的不同配置策略下，有些情況下的物理讀可能并不是真正的物理讀，而是“假物理讀”，因此針對PG數據庫，共享緩沖池命中率和物理讀這兩個指標是會存在比較嚴重的誤解的。

在Oracle數據庫中，我們會針對物理讀的突然增加產生一個性能告警。因為這可能意味著某些SQL執行存在異常，或者IO負載突然增加，可能會引發一些不確定的數據庫性能問題。

這個故障模型在D-SMART里也被拷貝到了PG數據庫中，但是這個故障模型的告警，在PG數據庫中可能沒有在Oracle上那么有效。因為不同的shared buffers配置策略可能會導致某些時候產生的物理讀實際上并不是真正的從存儲設備上讀取數據，而是從FILE CACHE中讀取數據。很可能這種突發的物理讀增加并不是一個需要告警的故障，而是一種被預先設計好的正?，F象，如果不分青紅皂白的去告警就會不準確了。作為一個通用的運維工具產品，我們又無法預知用戶的應用場景與設計理念，因此這個故障模型必須做改造。

數據庫緩沖命中率指標也存在類似問題，某些場景中，數據庫緩沖命中率低有可能是PG數據庫設定好的場景，無需告警。我們如果還是模仿Oracle的方式來預警則可能會產生大量的誤報。如果新增的“數據庫物理讀”大部分都產生了操作系統的物理讀，那么才需要進行告警，而如果新增的“數據庫物理讀”并沒有大幅增加OS的物理IO,那么這種現象可能是數據庫參數配置的正常現象，應該被自動排除。

針對數據庫緩沖區命中率的理解也是如此，當數據庫緩沖區命中率較低的時候，我們沒有必要直接報警，而是要看操作系統IO總量是否大幅度增加，如果操作系統IO總量沒有明顯增加，那么這種數據庫緩沖命中率的下降應該是正常的。

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

在D-SMART中，1000105這個指標的含義是關鍵指標異常，這是一個復合指標，是針對基礎指標進行異常檢測生成的。比如30000100是操作系統的IOPS指標，當這個指標出現大幅上升的時候，就意味著IO異常增長。因此在那兩個故障模型中，可以加入1000105[30000100]=4這個規則，從而讓告警更為精準。?