スキップしてメイン コンテンツに移動

続 Smart Flash Cacheの謎

先日、Smart Flash Cacheを実行した際に2回目が必ず遅いと書きましたが、あれから、ちょっと調べてみました。原因は単純なのですが。一応、ご報告です。

先日のテストを再度実行し、その時のv$sysstatのflash cache 周りの統計情報を見てみます。

flash cache insert skip: DBWR overloaded physical read flash cache hits flash cache inserts flash cache insert skip: exists
1回目 147593 2 206803 398
2回目 0 207038 147880 206680
3回目 0 354529 90 354406


正直、上記のイベントに関してキチンとしたドキュメントが存在しないので、想像の域を超えませんが、前回、x$bhから、対象セグメントのサイズの全てが、flash cache上に乗っていないと言いました。その原因が示されているようです。

それは、flash cache insert skip: DBWR overloadedだったから。というわけでしょう。DBWRが忙しすぎると、flash cacheに乗せる(というよりもきっとflash cache上に存在するのか?flash cache上に空きがあるのか?といった管理)作業をスキップするようです。結果として、flash cache上に全データが乗っていなかったと(ある意味)納得がいきました。

もう少し、見てみます。
1回目は、基本的にデータファイルから、buffer cache(このテストでは小さくしてあるので、ほぼ、flash cache)に乗せる作業となります。なので、flash cacheのデータにヒット(physical read flash cache hits)することは無く、また、flash cacheにはデータが存在しないので、既存データとしてスキップする(flash cache insert skip: exists)ことなく、全て、flash cacheにデータを乗せています(flash cache inserts)。ただし、DBWRが忙しかったので、一部のデータはflash cacheの乗せることをスキップしています(flash cache insert skip: DBWR overloaded)

2回目となると様相が変わります。
それは、かいつまんで言うと、physical read flash cache hitsと、flash cache insert skip: existsが増加し、さらに、flash cache insertsもソコソコ存在するということです。これは、簡単にいうとflash cache上でread / writeが、相当競合したであろうことを示しています。

3回目になると。
言わずもがな、ですが、flash cache insertsが激減(全部、flash cacheに乗ってしまった)し、ほぼreadのみの状態となりました。

ここまでで、お分かりのように、Smart Flash Cacheにおける、ready boost的なフラッシュキャッシュは、buffer cacheと同様に扱われます。が、SSDは物理メモリではありません。なので、物理メモリよりは随分遅いのです(普通のディスクよりはかなり高速なのですが)なので、物理メモリの補助として使用することを忘れると大変なことになります。
このテストの場合、buffer cacheを小さく設定しているので、ほとんどをflash cacheに頼っています。flash cacheでは自分のI/O性能を超えるもの要求されて、ニッチもサッチも行かない状況なのがうかがえます。特にこれは2回目のread / writeの競合で顕著にみえたということでしょう。

一応、その際のiostatの状況をまとめてみます。

Chart build on http://charts.hohli.com

Chart build on http://charts.hohli.com

Chart build on http://charts.hohli.com

コメント

  1. 2回目が一番遅かった原因は、1回目で flash cache 上にデータが乗りきらず、2回目でも HDD からの読み取りが発生し、さらに flash cache への read / write が競合したからということですね。

    あと、この検証では select しかしていないはずなのに1回目でなぜ DBWR が忙しいのか不思議に思ったのですが、SSD に書込むために DBWR が忙しいということですね。

    返信削除
  2. > 2回目が一番遅かった原因は、1回目で flash cache 上にデータが乗りきらず、2回目でも HDD からの読み取りが発生し、さらに flash cache への read / write が競合したからということですね。

    これは、iostat(今回乗せていなのですが)のutil%でSSDが100%となっていたことから、ご認識の通りですし、そのつもりで書きました。

    > あと、この検証では select しかしていないはずなのに1回目でなぜ DBWR が忙しいのか不思議に思ったのですが、SSD に書込むために DBWR が忙しいということですね。

    これは、きちんと調べていないのですが、一般論として、shadowプロセスは、buffer cacheに対してcache buffer lru chainラッチで空きを探しますが、空きが存在しない場合はdbwrがbuffer cacheのダーティブロックをデータファイルに書き出し or コールドブロックの掃除をします。(普通なら、free buffer waitsなどが発生するのだと思います)
    ここからは要検証事項なのですが、
    ここで、本来のbuffer cacheが足りない際に、DBWRがコールドブロックを掃除するのではなく、flash cacheの書き出します。が、disk -> buffer cache -> (不足) -> flash cacheという流れは余りにも処理が冗長ではないか? つまり、本当にそうなのか? だと実は思っています。

    返信削除
  3. >ここからは要検証事項なのですが、
    >ここで、本来のbuffer cacheが足りない際に、DBWRがコールドブロックを掃除するのではなく、flash cacheの書き出します。が、disk -> buffer cache -> (不足) -> flash cacheという流れは余りにも処理が冗長ではないか? つまり、本当にそうなのか? だと実は思っています。

    な、なるほど、興味深いです。

    返信削除
  4. 的外れかもしれませんが、ちょっと思いついたことをコメントさせて頂きます。

    泣いている子供をだっこしてあやしながらふと思ったのですが、この検証を実施されたときに使われていたI/Oスケジューラは何でしょうか?
    もし、ボトルネックがOSのレイヤーにあった場合、I/Oスケジューラが性能に影響するかもしれないと思いました。

    具体的には、I/Oスケジューラが deadline 以外であった場合、deadline にすると性能が向上するのではないかと思いました。

    read/write が競合するケースでは、読み込み・書き込みの両方をバランス良く処理する deadline だとスループットが向上するのではないかと思いました。

    返信削除
  5. いつもありがとうございます。
    この検証の時のI/Oスケジューラはcfqです。ご指摘のとおりdeadlineでスループットが変わるかも知れません。たしかにDBWR負荷がどのレイヤーの話しなのかはもう少し正確に検証すべきですね。

    返信削除

コメントを投稿