SSD Test

Micron C400 SSD登場で紹介したCrusial M4 SSD (Micron社のSSD。型番はC400)を旧製品のC300と比較してみた。

期待通り1本で500MB/sを超えた。

このブログを始めたときに初めて買ったSSDはKingston 30GB。4本のRAID-0で500MB/secで喜んでいた。1年で値段も下がり、倍のパフォーマンスとなった。

僕はおそらく日本一のMicron社SSDのファンです：

なのでMicron社の正規代理店株式会社エスティ トレードの方から最新C400を頂戴しました：

OCZ Technology社製 SATAⅢ6Gbps対応 SSD Vertex3 シリーズ

写真の240GB版は6万5千円と、非常に高価。しかし、今まで使ってきたCrucial RealSSDでは到達できなかった1本で500MB/sを上回るSequential Readが可能となる。
コントローラはSandForce2281を使用。（http://www.anandtech.com/show/4159/ocz-vertex-3-pro-preview-the-first-sf2500-ssd/1から引用）

Hadoopは、これ以上テストする魅力を感じなくなった。だから、SSDをたくさん積んだクラスタ・ストレージを用意した：

それをInfiniBand 40Gbpsで連結：

で、、、これをたくさん並べた：

「Peta Byteを超えるデータ量をスキャンする」のに1台のサーバでは無理がある。
だから、Hadoopということになる。でも「100台のサーバを揃えてテストをする」なんて趣味の範囲を超えてしまうのでできない。
取りあえず、以下の構成4台で、データ量も32GBにしてOracleと比較してみる。

OSもCentOS 5.5 (x86-64)にして、今回使っているAMD Phenom II X6 1100T Black Edition BOX(3.3 GHz/6 core)1台でDOP=6のOracleのパフォーマンスを見てみると：

前回の続き、、、
CompressでPQが速くなるのは、I/O量（回数）が減るからと前回書いた。
で、もっと無駄なFullScanを減らすのがPartitioning。１セッションでCompressだけだと>
それをPartition化してみると
そして、同時4セッションテストだと

最後に、
新品SSDを大事に使いたいから、以下のコマンドを入れてTPC-HのベンチマークでSSDにTemporary Segmentがとられないようにした：
SQL> alter tablespace tpchtab read only;
戻すときは：
SQL> alter tablespace tpch read write;

次に効果的なチューニングはTableの大きさを考慮したテーブルごとのDOPの設定となる。FORCEでDOPを乱暴に設定するのは好ましくない。が、前回、チューニングばかりに集中して、最後にわからなくなったので、ここまでとします。なぜなら、ASMと比較する（次回から）方が大事だからです。

create table lineitem
pctfree 1
pctused 99
initrans 10
storage (freelist groups 4 freelists 84)
parallel
nologging
partition by range (l_shipdate)
(
partition item1 values less than (to_date('1992-01-01','YYYY-MM-DD')),
partition item2 values less than (to_date('1992-02-01','YYYY-MM-DD')),
partition item3 values less than (to_date('1992-03-01','YYYY-MM-DD')),
partition item4 values less than (to_date('1992-04-01','YYYY-MM-DD')),
partition item5 values less than (to_date('1992-05-01','YYYY-MM-DD')),
partition item6 values less than (to_date('1992-06-01','YYYY-MM-DD')),
partition item7 values less than (to_date('1992-07-01','YYYY-MM-DD')),
partition item8 values less than (to_date('1992-08-01','YYYY-MM-DD')),
partition item9 values less than (to_date('1992-09-01','YYYY-MM-DD')),
partition item10 values less than (to_date('1992-10-01','YYYY-MM-DD')),
partition item11 values less than (to_date('1992-11-01','YYYY-MM-DD')),
partition item12 values less than (to_date('1992-12-01','YYYY-MM-DD')),
partition item13 values less than (to_date('1993-01-01','YYYY-MM-DD')),
partition item14 values less than (to_date('1993-02-01','YYYY-MM-DD')),
partition item15 values less than (to_date('1993-03-01','YYYY-MM-DD')),
partition item16 values less than (to_date('1993-04-01','YYYY-MM-DD')),
partition item17 values less than (to_date('1993-05-01','YYYY-MM-DD')),
partition item18 values less than (to_date('1993-06-01','YYYY-MM-DD')),
partition item19 values less than (to_date('1993-07-01','YYYY-MM-DD')),
partition item20 values less than (to_date('1993-08-01','YYYY-MM-DD')),
partition item21 values less than (to_date('1993-09-01','YYYY-MM-DD')),
partition item22 values less than (to_date('1993-10-01','YYYY-MM-DD')),
partition item23 values less than (to_date('1993-11-01','YYYY-MM-DD')),
partition item24 values less than (to_date('1993-12-01','YYYY-MM-DD')),
partition item25 values less than (to_date('1994-01-01','YYYY-MM-DD')),
partition item26 values less than (to_date('1994-02-01','YYYY-MM-DD')),
partition item27 values less than (to_date('1994-03-01','YYYY-MM-DD')),
partition item28 values less than (to_date('1994-04-01','YYYY-MM-DD')),
partition item29 values less than (to_date('1994-05-01','YYYY-MM-DD')),
partition item30 values less than (to_date('1994-06-01','YYYY-MM-DD')),
partition item31 values less than (to_date('1994-07-01','YYYY-MM-DD')),
partition item32 values less than (to_date('1994-08-01','YYYY-MM-DD')),
partition item33 values less than (to_date('1994-09-01','YYYY-MM-DD')),
partition item34 values less than (to_date('1994-10-01','YYYY-MM-DD')),
partition item35 values less than (to_date('1994-11-01','YYYY-MM-DD')),
partition item36 values less than (to_date('1994-12-01','YYYY-MM-DD')),
partition item37 values less than (to_date('1995-01-01','YYYY-MM-DD')),
partition item38 values less than (to_date('1995-02-01','YYYY-MM-DD')),
partition item39 values less than (to_date('1995-03-01','YYYY-MM-DD')),
partition item40 values less than (to_date('1995-04-01','YYYY-MM-DD')),
partition item41 values less than (to_date('1995-05-01','YYYY-MM-DD')),
partition item42 values less than (to_date('1995-06-01','YYYY-MM-DD')),
partition item43 values less than (to_date('1995-07-01','YYYY-MM-DD')),
partition item44 values less than (to_date('1995-08-01','YYYY-MM-DD')),
partition item45 values less than (to_date('1995-09-01','YYYY-MM-DD')),
partition item46 values less than (to_date('1995-10-01','YYYY-MM-DD')),
partition item47 values less than (to_date('1995-11-01','YYYY-MM-DD')),
partition item48 values less than (to_date('1995-12-01','YYYY-MM-DD')),
partition item49 values less than (to_date('1996-01-01','YYYY-MM-DD')),
partition item50 values less than (to_date('1996-02-01','YYYY-MM-DD')),
partition item51 values less than (to_date('1996-03-01','YYYY-MM-DD')),
partition item52 values less than (to_date('1996-04-01','YYYY-MM-DD')),
partition item53 values less than (to_date('1996-05-01','YYYY-MM-DD')),
partition item54 values less than (to_date('1996-06-01','YYYY-MM-DD')),
partition item55 values less than (to_date('1996-07-01','YYYY-MM-DD')),
partition item56 values less than (to_date('1996-08-01','YYYY-MM-DD')),
partition item57 values less than (to_date('1996-09-01','YYYY-MM-DD')),
partition item58 values less than (to_date('1996-10-01','YYYY-MM-DD')),
partition item59 values less than (to_date('1996-11-01','YYYY-MM-DD')),
partition item60 values less than (to_date('1996-12-01','YYYY-MM-DD')),
partition item61 values less than (to_date('1997-01-01','YYYY-MM-DD')),
partition item62 values less than (to_date('1997-02-01','YYYY-MM-DD')),
partition item63 values less than (to_date('1997-03-01','YYYY-MM-DD')),
partition item64 values less than (to_date('1997-04-01','YYYY-MM-DD')),
partition item65 values less than (to_date('1997-05-01','YYYY-MM-DD')),
partition item66 values less than (to_date('1997-06-01','YYYY-MM-DD')),
partition item67 values less than (to_date('1997-07-01','YYYY-MM-DD')),
partition item68 values less than (to_date('1997-08-01','YYYY-MM-DD')),
partition item69 values less than (to_date('1997-09-01','YYYY-MM-DD')),
partition item70 values less than (to_date('1997-10-01','YYYY-MM-DD')),
partition item71 values less than (to_date('1997-11-01','YYYY-MM-DD')),
partition item72 values less than (to_date('1997-12-01','YYYY-MM-DD')),
partition item73 values less than (to_date('1998-01-01','YYYY-MM-DD')),
partition item74 values less than (to_date('1998-02-01','YYYY-MM-DD')),
partition item75 values less than (to_date('1998-03-01','YYYY-MM-DD')),
partition item76 values less than (to_date('1998-04-01','YYYY-MM-DD')),
partition item77 values less than (to_date('1998-05-01','YYYY-MM-DD')),
partition item78 values less than (to_date('1998-06-01','YYYY-MM-DD')),
partition item79 values less than (to_date('1998-07-01','YYYY-MM-DD')),
partition item80 values less than (to_date('1998-08-01','YYYY-MM-DD')),
partition item81 values less than (to_date('1998-09-01','YYYY-MM-DD')),
partition item82 values less than (to_date('1998-10-01','YYYY-MM-DD')),
partition item83 values less than (to_date('1998-11-01','YYYY-MM-DD')),
partition item84 values less than (MAXVALUE))
as select * from lineitem_org;

ALTER TABLE lineitem MOVE PARTITION item1 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION item2 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION item3 COMPRESS;
..
ALTER TABLE lineitem MOVE PARTITION item81 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION item82 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION item83 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION item84 COMPRESS;
ALTER TABLE lineitem MOVE PARTITION item85 COMPRESS;

Parallel QueryはTable Compressを行うとI/O量（回数）が減って速くなる。
そこで、以前のテスト（Compressで40%アップ）と同じことをしてみた：
SQL> ALTER TABLE LINEITEM MOVE COMPRESS;
Compress前はということで、同じようにCompressの効果が大きいことがわかる。

そして、8月13日のテストではタイムオーバーとなった「同時4セッション」処理も、10分ぐらい掛かったけれど完走した：
TPC-HベンチマークのようなFull Scanは転送量が全てだから、マザーボード上のSATAインターフェースの限界があるIntel P55系のLGA1156マザーボードでは今回のような転送量が出せなかったからタイムオーバとなった。これをLGA1156マザーボードでやろうと思ったら、10万円ぐらいするRAIDボードをPCI Expressバスに積まなければならない。あるいは、高価なSANデバイスを購入する。。。

今回はAMDに乗り換えて、たった4本のSSDで、900MB/sでParallel Queyが実行できたのだから、RAIDカード1枚より安いよね。SSDを2枚追加すれば1GB/sを超えるはずです。
今回の転送量：

最後に、
貴重なPCI ExpressバスはInfiniBandで使う。

週間アスキーの「ジサトラ」を読んでいたら、僕の使ったP55マザーやX58マザーではMarvell 9128などの外部チップがPCI-E2.0 x 1で接続しているので、いくらSSDでRAID0にしても500MBの壁は破れないと書いてあった。なるほど、、、それらしい値が出た。
でも、8000円のSSDだから「満足」してしまって、高価なSSDならもっと速い！と思い込んでいました。。。
なんと、AMD800系マザーだとSATA3コントローラが性能が良く、当然RAID0接続でもこのようなことは起きないと書いてある。
最近ずっと追いかけてきたTPC-Hベンチマークでは、500MB-530MB/secぐらいでdirect path read待ちばかりとなるから、RAIDカードを買い足そうと考えていたのだけど、まだ買う前でよかったです（忙しすぎて却ってよかった）。
mini DWHにはAMDフェノムですかね？（直ぐ注文）

前回In-Memory PQはdirect path readではなくてsequential readとscattered readでbuffer_cacheに読み込むと書いた。
今回のシナリオは、

• 対象が全てIn-memoryに有り、最高のスループットを出していた
• しかし、月日の経過とともにデータ量が増え始め、ディスクI/Oで「継ぎ足しながら」In-Memory PQが動くようになった

同時4セッションで」のhammerora TPC-Hを動かした状況で

ASH Viewerでみると、scatterd readとsequential readの待ちが多く発生している。
read by other sessionのコンテンションが際立っている（前回の新久保君のコメント通り）。
もう少しデータを増やしてみると：

memory_targetで指定した領域が足りなくなり、3セッションがdirect path readでbuffer_cacheを使わないParallel Queryを行うように変わった。

こんな状況になってたら（#572406;">cache buffers chainsラッチミス より）：

■データ量に「見合わない」実メモリしか積んでいないと「あきらめる」
■In-Memory Parallel Queryを使わない。pararell_degree_policy=MANUALに戻す。
■或いは、Partition化してbuffer_cacheに収まるサイズに縮小する

前回は、強引に「cache buffers chainsラッチミスが慢性的に発生しているときは」と書いてしまったけど、In-Memory Parallel Queryが使えない状況をLatch Timeoutのような「いち」現象から言い当てるのは難しいです。
なぜならば、AUTO指定でParallel Queryが動いたとたん、待機要素のパーセンテージはdirect path readに独占されるからです。（テストで使用しているSSD　x　4のRAID0は、何度も書いていますが、520MB/sでデータ転送をしているのにも拘らずです。）

In-Memory Non Parallel Queryのテストなんて、あまり見かけない。
でも「Parallel Queryが使えないOracle SEでmini DWHができるか？」という意味でテストをした。
それに今回の試作機は16GBのメモリを積んだんだから、メモリを使い倒すテストはやりたくて仕方がなかった。

当然、次回からはIn-Memory Parallel Queryのテスト結果をBlogするのだけど、今回は、これまで結果を整理することにした。

今までの結果をグラフにしてみた

　　　　　　　　　　　　　　　[X軸=同時セッション数、Y軸=qph(Query Per Hour)]

でも、これをセッション数で割ると：

そしてIn-Memory non Parallel Queryじゃダメなんだよ！の中で、

In-Memory nonParallelはTPC-Hの総合点には大きく貢献したが、実際のデータウェアハウスではParallel Queryの方が優れていることが確認できた。
そして、Parallel Queryは初めから限界ディスク転送量を出してしまうので「同時実行制御」の工夫が必要だということが、今回のテストを通じて理解できた。

と書いた。

ディスク転送量はCrystalDiskMarkの限界量522MB/sを常に超える場合もあった(T2)。
でもReadされているデータは殆んどが必要のないもの、Readしてメモリ上でフィルタリングされる。
1分間のRead量は：

500MB/s x 60(秒) = 30000MB = 30GB　　....たった1分で実際のデータ量を簡単に超えている。

Exadata Storage ServerがインテリジェントにWhere条件をフィルタリングして結果を返したり、Join条件をハッシュ値として返すことが重要な機能だということが実感できた。
以前Oracle Closed Worldの中で、

でもStorage Server内での「Secondary Oracle」はExadataだけのClosedなものでしょ？
→そんなのこれからも「どんどん変わる」。既に細かな話になり始めている。

と書いた。
「SSDの普及で転送速度が上がればフィルタリングなんてそれほど重要じゃなくなる」というのは認識不足でした。

でも、
TPC-Hベンチマークのように同時8セッションがThink Time無しにHeavy SQLを発行し続けるようなことは、現実世界ではあまりないので、2セッションぐらいで限界になるParallel Queryが活躍できるんだね。
そうそう、T4はCompress+Partitioningで実質Read量を減らしたので、6セッションまで行けた。

それから、
In-Memoryはスケーラビリティでは大勝です。
でも、メモリに収まるサイズだからです。。。