（轉）資料庫Flash Cache(II)

資料庫Flash Cache(II)

我非常期待我的高效能Flash SSD(一個Intel X-25E),但同時,我已經在一套便宜的硬體裝置上(我的中對此做了說明)做了很多資料庫Flash Cache的測試. 有時,在較差的硬體上測試新特性也非常有用,因為你可以觀察到一些在高速執行的環境下不會發生的現象.
最初,我天真地認為資料塊會被Oracle的服務程式複製到Flash Cache中.比如,當我從磁碟讀取的時候,同時將資料塊放到Buffer Cache與Flash Cache中.然而,透過觀察,實際情形可能是, 當資料塊將要被刷出Buffer Cache的時候, 由DBWR程式將此資料塊從Buffer Cache移入到Flash Cache中.
當然,這是一種更好的處理方式.DBWR可以非同步的將資料塊寫入Flash Cache中,從而使用者會話可以獲得好處,在資料塊寫入Flash Cache中的時候不需要進行等待(比從磁碟讀取耗費更少的時間).
因此,一個資料塊可能有一個如下圖的生命週期:

• Oracle服務程式從磁碟讀取檔案的一個資料塊,並將其放到Buffer Cache中
• 如果一個會話在稍後需要訪問這個資料塊,並且這個資料塊仍然在Buffer Cache中,就可以直接從Buffer Cache中讀取這個資料塊
• 在這個資料塊離開Buffer Cache之前,DBWR將它寫入Flash Cache(如果DBWR不是太忙的話)
• 如果一個會話稍後需要訪問這個資料塊,並且它還在Flash Cache中的話,就可以從Flash Cache中讀取這個資料塊(有可能會將這個資料塊放回到Buffer Cache中)
• 如果這個資料塊被修改了,DBWR程式最終會將這個資料塊寫回磁碟.(問題:Flash Cache中那些沒有被修改過的資料塊會發生什麼呢?)

DBWR 與 Flash Cache

從快閃記憶體上讀取的速度是非常快的,但是往快閃記憶體上寫就要慢很多了.因此,為了避免效能問題,DBWR程式應該:

• 1. 不要去寫快閃記憶體, 除非不得不寫,並且
• 2. 如果有其他更重要的活動的話,一點都不要寫快閃記憶體.

對於第一點,在資料塊將要被刷出Buffer Cache之前,DBWR程式不要填充Flash Cache.也就是說,DBWR不會為了防止資料塊將要被刷出Buffer Cache去寫這個資料塊,而只是這個資料塊確實(或許是可能性很高的時候)將要被刷出Buffer Cache的時候才會將其寫入Flash Cache.在資料塊被寫入Buffer Cache的時候,我們沒有發現對Flash Cache的寫操作, 同時有其他資料塊被刷出Buffer Cache的情況除外.
第二點,當DBWR忙於將髒塊寫入到磁碟的時候,不會去寫Flash Cache,也不會推遲將要被刷出Buffer Cache的資料塊的刷出時間.DBWR程式必須儘可能塊地清除Buffer Cache中的髒塊,否則”free buffer waits”等待事件就會阻止新的資料塊被讀入Buffer Cache中.如果資料塊將要被刷出Buffer Cache,而同時DBWR程式又很忙,這些資料塊將不會被寫入Flash Cache,統計資訊項’flash cache insert skip: DBWR overloaded’將出現增長.

度量DB Flash Cache的效率

下面的報告了DBWR由於太忙或其他原因而跳過寫Flash Cache的次數:

• 我認為我理解”DBWR overloaded”統計項的意思,DBWR忙於寫髒塊到磁碟而沒有足夠的處理能力來將乾淨的資料塊寫入Flash Cache.
• “flash cache insert skip: exists”統計項也比較容易理解.如果我們從Flash Cache將一個資料塊讀回Buffer Cache,它還會繼續保留在Flash Cache中.當它再次在Buffer Cache中被刷出的時候就不再需要寫入Flash Cache了.
• “not current”統計項可能表示,DBWR明白磁碟或者Buffer Cache中還有這個資料塊的一個更新的複製,因此拒絕寫一個版本到Flash Cache上.
• “not useful”統計項,我無法理解…

我認為這裡最大的啟示是:
在一個DBWR非常繁忙的系統上,DB Flash Cache可能會非常無效率.
要測量出使用Flash Cache帶來的好處,我們可以計算由於使用Flash Cache而被避免掉的物理讀的次數,以及乘上每種讀操作耗費的平均時間.下面嘗試做這個對比,雖然僅僅針對單塊讀操作:

結論

DB Flash Cache的架構使得我們可以對與快閃記憶體SSD相關的相對糟糕的寫效能可以顯得稍微放鬆一點.如果我們將資料檔案放到快閃記憶體SSD上,我們可能會有遭遇”free buffer waits”瓶頸的風險: DBWR可能會由於嘗試往低速(從寫延遲的角度上看的話)的快閃記憶體盤上寫資料塊而中止,相對於磁碟來講,我們可能實際上遭遇了更糟糕的效能,至少對於有非常高的寫頻率的應用來講.相應地,幾乎不應該出現實際的負面因素,可能出現的更糟糕的情況是,DBWR太忙,以致於不會去填充Flash Cache,而使得Flash Cache變得更加無效.
DB Flash Cache的效率依賴於以下兩個主要因素:

• 1. DBWR是否有足夠的空間事件來寫Flash Cache?
• 2. DBWR需要花費多長事件類寫快閃記憶體裝置?

第一個問題的答案依賴於DBWR當前的活動效率,可能也相應地依賴於你當期的磁碟陣列有多少可用的寫頻寬.但是,如果你的資料庫已經遭遇或者將要遭遇”free buffer waits”,那麼DB Flash Cache可能無法正常發揮作用,因為DBWR可能永遠不會寫Flash Cache.
第二個問題的答案依賴於快閃記憶體SSD的品質.通常你會選擇使用擁有最小寫延遲的快閃記憶體盤.那通常也意味著支援TRIM API呼叫,並且是使用SLC(Single Level Cell)的快閃記憶體.