Strip SizeとAllocation Unit Size

前回のテストでは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

その結果
だから_db_file_direct_io_count = 524288 = 512KB のときが安定している。

もし8本でストライピングしたら_db_file_direct_io_count = 1048576 = 1MBで安定するはずだ。

Striping SizeやAllocation Unit Sizeが大きいのはデータウェアハウス専用機として
direct path readの性能を出すための設定だ。
OLTP環境には相応しくない。

最後に、

db_file_multiblock_read_count=64と128では「それほど」差はなかった。
そして、その差はちょっと前のX86アーキテクチャ以前の環境であれば逆転するはずだ。
なぜならRead System Callが重いからだ。128であれば2分の1のRead System Callですみ、それが結果に反映される。

一部Unix環境ではそのReadの重さを解決するためにlist_io system callが用意されている。それを使うためにuse_list_io=TRUEと設定する。

しかし、その設定も「それほど」効果は出なかった。

なぜならば、
Oracle11gの_adaptive_direct_read = TRUEで設定されている「最適化」機能が合わせて提供されていなかったからだ。

Adaptive＝最適化　と訳すと全てが繋がって見えてくる。

今回のテストをOS側から見ると：
read read read read read read read read ................
read read read read read read read read ................
...............................とても単純なことをやっている。