Smart Flash Cache の使い道

Smart Flash Cache自体、現在のBuffer Cacheの代替キャッシュ(L2 キャッシュ)という位置づけでしかないが、使い道はそれなりに多い。メインメモリ(DDR3)4GBが10000円前後であるのに比べ、SSD 64GBは15000円前後です。SSDは、Buffer Cacheの不足を補うには、もってこいのデバイスと言えるでしょう。

ただし、これは、"あくまでもOLTP系の処理"に限定したものです。OLTP系の処理では、インデックスを使用したアクセスが前提です。またインデックスアクセスは、基本的にバッファ上に存在する(してほしい)事も前提です。DWHのようなシステムでは、バッファ上に乗り切らないので、バッファを迂回したdirect path readを使用します。(が、これもin memory parallel Queryの登場で変わってくるかも知れません)

あと、OLTP系のシステムで、SQL文がそれなりにチューニングされている場合、全体のスループットを上げる方法として、メモリを大容量にする。か、ちょろちょろ発生するディスクアクセスを超高速にする。しかありません。実際、現在のディスクで最速なものはSSDとなるわけですが、SSDへデータを移動するには通常のデータ移行にみられるような、システムの停止を含む業務への影響や、データ移行に伴う様々のリスクが存在します。

Smart Flash Cacheは、WindowsのReady Boostなみに簡単にパフォーマンスアップが望めます。それもリスクなしで。SSD 64GB程度を15000円程度で購入し、デバイスごとOracleに認識させるだけです。本当にそれだけです。(といっても、街の電気屋さんで買って、すぐに商用環境にくっつけるには勇気がいるでしょうが...)

では、再度、Smart Flash Cacheのパフォーマンス比較をしてみましょう。

環境)
memory_target = 4.5GB
swingbenchにてTPC-Cベースの負荷を掛けます(swingbench用スキーマは約30GB程度です)
セッション数は15

1) 普通にベンチマークを実施

ベンチマークの結果)
平均のTPMが4692で、最高のTPMでも6696に留まっています

ASH Viewerの結果)
15セッションのほとんどがUser I/Oクラスの待機イベントで待たされていることが分かります。

またUser I/Oクラスの内訳はdb file sequential read(index scan)であることが分かります。

以前、「まず初めに」で述べたようにswingbenchはかなりチューニングされているベンチマークソフトですが、index scanでかなりの待機が発生しています。この答えを先にいってしまうと、TPC-Cはorder - entryのシステムをシミュレーションしているので、多くの「発注」と「確認」が発生します。「発注」は主にinsertとなるのですが、重複発注を防ぐようにUniqueチェックが入ります。ここで、index scanが多く発生し、結果、待たされる。ことになります。
これは、小幡さんのブログにもありましたね。


2) Smart Flash Cacheを使用してベンチマーク実施

- Smart Flash Cacheを50GB分確保

alter system set db_flash_cache_size=50G scope=both; 

- いくつか大事なオブジェクトをFlash Cache上にキープさせる(前に50GBで大丈夫か確認)

select segment_name, sum(bytes)/1024/1024 segment_size_MB
from user_segments
where  segment_name in ('CUSTOMERS', 'CUSTOMERS_PK', 'ORDER_ITEMS'
                                    ,'ORDER_ITEMS_PK', 'ORDERS', 'ORDER_PK')
group by segment_name;

SEGMENT_NAME                    SEGMENT_SIZE_MB
------------------------------ ----------------
CUSTOMERS                                  3072
ORDER_ITEMS                                3776
ORDER_PK                                    790
CUSTOMERS_PK                                703
ORDERS                                     2752
ORDER_ITEMS_PK                             2808

- いくつか大事なオブジェクトをFlash Cache上にキープさせる

/* これは、Flash Cacheに事前に乗せる際にdirect path readでバッファーを迂回しないおまじない */
alter session set events '10949 trace name context forever ,level 1';
alter session set "_very_large_object_threshold"=1000000;

/* 以下は大事なオブジェクトをFlash Cache上に乗せる */
alter table customers storage(flash_cache keep);
select /*+ no_parallel index(c customers_pk) */ count(*) 
from customers c where customer_id>=0;
alter index customers_pk storage(flash_cache keep);
select /*+ no_parallel no_index(c) */ count(*) 
from customers c;

alter table order_items storage(flash_cache keep);
select /*+ no_parallel no_index(c) */ count(*) 
from order_items c;
alter index order_items_pk storage(flash_cache keep);
select /*+ no_parallel index(c order_items_pk) */ count(*) 
from order_items c where line_item_id >=0 and order_id>=0;

alter table orders storage(flash_cache keep);
select /*+ no_parallel no_index(c) */ count(*) 
from orders c;
alter index order_pk storage(flash_cache keep);
select /*+ no_parallel index(c order_pk) */ count(*) 
from orders c where order_id >= 0;

ベンチマークの結果)
平均のTPMが9726で、最高のTPMで15045と、平均のTPMで約2倍のパフォーマンスアップとなっています。

ASH Viewerの結果)

User I/Oの待機が減って、その分、多少CPUを使えるようになりました。

User I/Oの待機は以前、db file sequential readですが、全体的に減少しています。

ただ、もう少し、チューニングの余地はありそうです。