CrystalDiskMark

P55マザーやX58マザーではMarvell 9128などの外部チップがPCI-E2.0 x 1で接続しているので、いくらSSDでRAID0にしても500MBの壁は破れない。。。だから、SSDを追加しても、TPC-Hベンチマークでは、500MB-530MB/secぐらいでdirect path read待ちを増やすだけです。
今までのマザーボード：
新たに購入したマザーボード：
プロセッサーはAMD PhenomII - X6 1090T。マザーボードと合わせて合計で35000円ぐらい。

早速CrystalDiskMarkでテストを行う：
今までは：だったので、これを上回ることができた。

今回のマザーボード（GIGABYTE社のGA-890GPA-UD3H)ではSB850インターフェースにSATA3(6Gb/s)が6個接続できる。そこで、
まず、SATA3に対応したSSDが使える。そして、後2個のSSDを追加することができる。

SATA3対応のSSDはコントローラがMarvel社製の物しか現在はない：

思い切って、crucial REAL SSD 64GB4本を追加購入。（後2本をケチってしまった）

ここまでやるとTPC-Hのテストを実施するまでもなく結論が見える。でも、最後のCrystalDiskMarkが実行できないASM-RAWデバイスとの比較ができなくなるので、次はTPC-Hを行う。

TPC-Hベンチマーク続き

前回のIn-Memory nonParallel Queryでは「同時セッション数」の増加とともに、スケーラブルにqphは上がった。そして、8セッションでCPUの限界となった。

しかし、Parallel Queryでは、そうは行かない。
同時1セッションでは：

同時4セッションでは：

同時6セッションでは：
qphはそれほど変わらない。

結果として、6セッションのときのユーザ・レスポンスは1セッションのときの6倍遅いということになる。

今回使用したKingstonのお買い得SSD4本で構築したRAID-0のCrystalDiskMarkで計った限界量は

前回のテストではI/O buffer sizeを最適化することによりdb_file_multiblock_read_count = 64でも安定するようになった。そして、全体を通してみると、この64の結果が一番よい：
db_file_multiblock_read_count = 64, _db_file_direct_io_count = 524288

db_file_multiblock_read_count = 128, _db_file_direct_io_count = 1048576画面右上に出ている数値は最後のサンプリングタイミングでの数値。平均ではない。

今回の試作機はKingstonのお買い得SSD4本でRAID-0を構築した。

そのときのStrip Sizeは128KBとした。

このサイズはIntel Matrix Storage ManagerでRAID0を設定するときの最大値だ。
そして、exFAT形式のファイルをフォーマットするときに、

Allocation Unit Sizeを512KBとした。128KB x 4本 = 512KB

その結果

前回の続きでKingstonのお買い得SSD4本で構築したRAID-0のTPC-Hベンチマークを行った。

初めは、１セッション、パラレル度=6でテスト：

そのときのディスク転送量は：
300-400MB/s程度しか出ていない。

CrystalDiskMarkで計った限界量は
1GBのReadで最高522MB/sを出しているのに、およそ120MB足りない。

そこで、4セッションにして、もう一度実行してみた：

TPC-Hの環境をKingstonのお買い得SSD4本で構築したRAID-0に構築した。
以前のCrystalDiskMarkの結果は以下のとおりだった(SATA直結のRAID-0、exFAT 512K)：
比較対象としたのは、Western Digital社のWD6000HLHX。SATAIII　6Gb/秒で接続可能な10,000 RPMハードドライブ
CrystalDiskMarkの結果は以下のとおりだった：
150万件のORDERSを外部表として使う：

SQL> desc orders
 名前                                      NULL?    型
 ----------------------------------------- -------- ----------------------------
 O_ORDERDATE                                        DATE
 O_ORDERKEY                                NOT NULL NUMBER
 O_CUSTKEY                                 NOT NULL NUMBER
 O_ORDERPRIORITY                                    CHAR(15)
 O_SHIPPRIORITY                                     NUMBER
 O_CLERK                                            CHAR(15)

前回のテストで書き込みキャッシュの有効性を確認できた。

しかし、Shared Diskで使う場合はこの設定をしてはいけない。

停電対応のためだけにDisableにしなさいというのであればUPS電源を確保した環境であれば補える。
RACクラスター構成も使わないのであれば、メモリ障害などの危険性もないわけではないが、

これほど有効な設定を使わない手はない。

前にやったベンチマーク結果をもう一度おさらいすると：
メモリのWriteアクセススピードは約7.6GB/s

ディスクはTPC-Cの場合はランダムWriteを注目すべきなので約2.6MB/s

おおよそ2900倍の差がある。

最後に、
書き込み負荷でtpmが回らなかったのだから、4本のHDDでストライピングし解決したとすると、
当然tpmは上がり、CPUもある程度Busyになってくる。
そこでRAC構成にしてスケーラビリティを上げようとすると、書き込みキャッシュがいきなり「禁じ手」になる。
結果、2台のRACで1台で出したtpmと「同じ程度」しか出せない。
RACでスケーラビリティを上げようと思ったら4本のストライピングじゃ全然足りない。なぜならばWrite Busyを少しでも発生させると2900倍の差が発生するからだ。

VM環境テストで性能が上がらないケースにも当てはまる。