TPC-Hをチューニングする（200%アップ？)

前回までのおさらい

1. ディスク転送量を上げるために１セッションのテストを行ってきた
2. その結果420から450MB/sがでた
3. qphを上げるためにpartitioning+compressを行い最高300%アップが達成できた

当初はdirect path readを効率化すれば、おのずとディスク転送量も上がり、結果TPC-Hベンチマークの得点もあがるはずと考えていた。しかし現在は、

• qphは上がったがディスク転送量は200MB/s程度となった
  Compressして読み出す量が減ったから下がるのは当然？
  月単位のPartitioningでParallel Queryが効果的に働いたから？
• CPU%は最高でも20%程度しか回っていないのに
  Compressして読み出す量が減ったら、もっと次をdirect path readしてほしい！
  月単位のPartitioningでParallel Queryを効率的にしたのだから、もっとdirect path read量を増やしてほしい！

大体、安定していないのは反則の300%アップだ！

セッション数を増やしてみる

DOP=4でセッション数2->4->8と増やしてみると：CPUは回りましたが、殆んどがdirect path read待ちの元の悪い状況に逆戻りしました。

DB OptimizerではCPU Max(赤線)をProcessor Queue Lengthで見ている。
Unix環境であればRun Queueだ。
このブログでもCPU%を指標として書いてきたがProcessor Queue Lengthを指標としたほうが的確だ。
今回のテストの場合、8セッションでCPU%はMax70%程度。しかしProcessor Queue Lengthは実装Core数を超え、処理はQueuingされるだけとなっていることが分かる。

CPU%はdirect path read待ちでProcessor Queuingされ回らない。

最後に、

今回の試作機でTPC-HをThink Time無しに激しく動かすと同時2セッションが限界ということになる。
結局4台のSSDでRAID0にして520MB/sのSequential Read幅を持たせてもセッション数の増加とともにdirect path read待ちが指数関数的に増加する。520MB/sじゃ足りない、、、
同時2セッションくらいで限界？