hammerora

TPC-Hベンチマークの続き

In-Memory-nonParallelでの最高結果は同時8セッションで：

今度はResult_Cacheを使ってみると：
同じ8セッションで最高値15000qphを記録した。

result_cacheが効く場合と効かない場合

TPC-HベンチマークのHeavy SQL Top5からひとつ選んで「Where条件」を変えるテストを行ってみた。

buffer_cache flush後

SQL> select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
  2  from customer, orders, lineitem
  3  where o_orderkey in
  4  ( select l_orderkey
  5  from lineitem
  6  group by l_orderkey
  7  having sum(l_quantity) > 312)
  8  and c_custkey = o_custkey
  9  and o_orderkey = l_orderkey
 10  group by c_name, c_custkey
 11  , o_orderkey
 12  , o_orderdate
 13  , o_totalprice
 14  order by o_totalprice desc, o_orderdate;
...
...
15行が選択されました。

経過: 00:00:08.52

統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     145349  consistent gets
      83465  physical reads
          0  redo size
       1725  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         15  rows processed

8.52秒かかった(physical readsが発生しているから)

having sum(l_quantity) > 312)を313に変えて実行してみる：

SQL> select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
  2  from customer, orders, lineitem
  3  where o_orderkey in
  4  ( select l_orderkey
  5  from lineitem
  6  group by l_orderkey
  7  having sum(l_quantity) > 313)
  8  and c_custkey = o_custkey
  9  and o_orderkey = l_orderkey
 10  group by c_name, c_custkey
 11  , o_orderkey
 12  , o_orderdate
 13  , o_totalprice
 14  order by o_totalprice desc, o_orderdate;
...
...
12行が選択されました。

経過: 00:00:00.01

統計
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
       1563  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         12  rows processed

択された行数も違うのにresult_cacheが効いて0.01秒で終わった。

もう一度312に戻すと：

SQL> select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
  2  from customer, orders, lineitem
  3  where o_orderkey in
  4  ( select l_orderkey
  5  from lineitem
  6  group by l_orderkey
  7  having sum(l_quantity) > 312)
  8  and c_custkey = o_custkey
  9  and o_orderkey = l_orderkey
 10  group by c_name, c_custkey
 11  , o_orderkey
 12  , o_orderdate
 13  , o_totalprice
 14  order by o_totalprice desc, o_orderdate;
...
...
15行が選択されました。

経過: 00:00:00.02

統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          0  consistent gets
          0  physical reads
          0  redo size
       1725  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
         15  rows processed

recursive callが発行され0.02秒となったが、result_cacheは効いた。

今度は314にしてみる：

SQL> select c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice, sum(l_quantity)
  2  from customer, orders, lineitem
  3  where o_orderkey in
  4  ( select l_orderkey
  5  from lineitem
  6  group by l_orderkey
  7  having sum(l_quantity) > 314)
  8  and c_custkey = o_custkey
  9  and o_orderkey = l_orderkey
 10  group by c_name, c_custkey
 11  , o_orderkey
 12  , o_orderdate
 13  , o_totalprice
 14  order by o_totalprice desc, o_orderdate;
...
...

10行が選択されました。

経過: 00:00:04.17

統計
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     145349  consistent gets
          0  physical reads
          0  redo size
       1463  bytes sent via SQL*Net to client
        520  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
         10  rows processed

result_cacheは効かなかった。しかし、buffer_cache scan(physical reads=0)で4.17秒で終わった。

結果がまったく同じでなくともresult_cacheは働く。
その理屈は、僕には説明できない。

因みに、Exadata1のTPC-Hベンチマークでも：
result_cache_mode = FORCE　を設定している。

TPC-Hベンチマーク続き

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

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

同時4セッションでは：

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

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

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

TPC-Hベンチマークの続き

Parallel Queryをやめて、Buffer_Cache=5GBですべてをOn Memoryとした：

同時ユーザを4セッションに増やしてみた：

その時点でCPU%は50%。

倍の8セッションに増やす：
CPU 100%ととなり、Intel Core i7 860（実売価格25000円）は限界。

qphは10000を超えた。

Parallel Queryで「ほぼ安定する」最高qphは：

TPC-Hベンチマーク続き
前回のCompressを行う前は：

次にLINEITEMをl_shipdateでPartitioningしたら

そして、各パーティションをCompressしたら、2倍以上のqphをたたき出した

Partitioning前はLINITEMが全体の70%の負荷オブジェクトだったが、今では負荷はある程度分散された。

TPC-Hの続き、

前回の分析でLINEITEMのdirect path readアクティビティが高いのが分かった。
そこで、表圧縮をしてみる：

SQL> ALTER TABLE LINEITEM MOVE COMPRESS;

前回の結果：

TPC-Hベンチマーク指標のqphが40%以上改善された。

そして、DB Optimizerで比較してみると：
今回

前回のテストでは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_multiblock_read_count=64のとき、安定しない結果に終わった。
そして「ディスク転送量＋アルファ」の何かがあると書いた。

_db_file_direct_io_count　：　Sequential I/O buf size

今回のテストはBLOCK_SIZE=8K=8192Bでテストをしている。
このI/O buffer sizeを最適化してからテストを再度行う：

db_file_multiblock_read_count = 64, _db_file_direct_io_count = 524288

db_file_multiblock_read_count = 128, _db_file_direct_io_count = 1048576
db_file_multiblock_read_count = 256, _db_file_direct_io_count = 2907152

TPC-Hベンチマークの続き、

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

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

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

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

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

TPC-Cベンチマークの番外編として、Windows7の書き込みキャッシュ機能の調査をしました。

今回のテストではデバイスマネージャのプロパティ設定にある

「書き込みキャッシュ ポリシー」→デバイスの書き込みキャッシュを有効にするだけで行いました。

デバイスでWindowsによる書き込みキャッシュバッファのフラッシュをオフにするもテストしてみました：

tpmが少し安定しているのがわかります。

そして、最後にすべてをオフにしました：

書き込みキャッシュがとても有効なことがわかります。

そうか、、、前回の安定しない「波形」は書き込みキャッシュの周期的なフラッシュだったんだな。