同時4セッション In-Memory Parallel Query

TPC-Hベンチマークの続き
In-Memory Non PQは8セッションまで、ある程度スケーラブルに処理能力は上がった（TPC-Hの結果参照）。
しかし、In-Memory PQはIn-Memory Parallel Queryセッション数でテストしたように、同時4セッションでqphは横ばいとなった。
念のために、もう一回4セッションをテスト：そして、CPU%は、前回とほぼ同じ「殆んど100%」で振り切れていた。

無駄なCPUはLatch TimeoutのSPINを調べるのが定石

statspackで分析してみると：

 Parent Latch Statistics DB/Inst: ORACLE/oracle  Snaps: 13-14
-> only latches with sleeps are shown
-> ordered by name

                                     Get                                Spin
Latch Name                      Requests       Misses     Sleeps        Gets
------------------------ --------------- ------------ ---------- -----------
Real-time plan statistic           7,048        1,133        107       1,026
active service list               25,346        2,817      1,716       1,139
call allocation                   41,422        2,215         39       2,177
dummy allocation                   9,807        1,635          2       1,633
enqueues                          63,653        3,107         10       3,097
messages                           9,540            4          1           3
parameter table manageme          24,461        2,459          1       2,458
qmn task queue latch                  52            1          1           0
query server process                  31           11         24           0
resmgr:free threads list           9,808        1,488          1       1,487
          -------------------------------------------------------------
 Child Latch Statistics DB/Inst: ORACLE/oracle  Snaps: 13-14
-> only latches with sleeps/gets > 1/100000 are shown
-> ordered by name, gets desc

                         Child          Get                                Spin
Latch Name                 Num     Requests       Misses     Sleeps        Gets
---------------------- ------- ------------ ------------ ---------- -----------
cache buffers chains     49990    2,791,680        5,344         32       5,313
cache buffers chains     42860      112,396        2,595          4       2,586
cache buffers chains     37884       91,118        3,150          2       3,148
cache buffers chains     31347       16,878        1,166          1       1,165
cache buffers chains     16597        5,280            4          1           3
cache buffers chains     48852        5,280            3          1           2
cache buffers chains     10163        5,200            3          1           2
cache buffers chains      4153        4,570            2          1           1
cache buffers chains     13172        4,568            1          1           0
cache buffers chains     14344        4,564            2          1           1
cache buffers chains     18218        4,564            2          1           1
cache buffers chains     46359        4,560            2          1           1
cache buffers chains     47367        4,560            2          1           1
cache buffers chains     55125        4,560            1          1           0
cache buffers chains     65459        4,560            4          1           3
cache buffers chains      6706        4,560            3          1           2
cache buffers chains      5678        4,560            2          1           1
cache buffers chains     17931        4,560            3          1           2
cache buffers chains     36331        4,560            1          1           0
cache buffers chains     43826        4,000            2          1           1
cache buffers chains     23857        3,440            5          1           4
cache buffers chains     49962        3,040            3          1           2
cache buffers chains     42216        3,040            3          1           2
cache buffers chains       345        3,040            1          1           0
cache buffers chains     51797        3,040            1          1           0
cache buffers chains     26238        2,885            2          1           1
cache buffers chains     35482        2,880            1          1           0
cache buffers chains     32567        2,880            3          1           2
cache buffers chains     39474        2,495            3          1           2
cache buffers chains     30680        2,480            1          1           0
cache buffers chains     44458        2,480            1          1           0
cache buffers chains     20453        2,480            3          1           2
cache buffers chains     46045        2,480            1          1           0
cache buffers chains     11421        2,480            1          1           0
cache buffers chains     31662        2,160            4          2           3
cache buffers chains     29644        1,920            1          1           0
cache buffers chains     33569        1,520            3          1           2
cache buffers lru chai      45       54,182          211          2         209
object queue header op      23       54,897        1,443          1       1,442
object queue header op      18       54,867        1,173          2       1,171
object queue header op      24       54,844        1,457          1       1,456
object queue header op      22       54,823        1,386          5       1,381
parallel query stats         1        5,720          920         13         907
process queue                6        2,526          110          2         108
process queue referenc      30      128,252           18          3          16
shared pool                  1      133,446       14,215         21      14,194
shared pool                  2      127,339       19,019         12      19,007
          -------------------------------------------------------------

cache buffers chainsでLatch get missがたくさん発生していた。
Oracle8の時代ならば_db_block_hash_bucketsやdb_block_lru_latchesなんてパラメータがあったのだけれど、11gではない。

一度にREADするBUFFER_CACHEの量を減らせばcache buffers chainsのLatch範囲も減る予感がする

db_file_multiblock_read_countを64->32に変更：あれ？同じ4セッションでキューイング管理が働いてしまった。

CPU%は：断続的に開放されている。
これは、In-Memory Parallel Queryセッション数でのテスト結果では同時8セッションで発生した現象だ。
そしてそのときは、以下のように書いた：

8セッションからのキューイング管理は実装CPUのスレッド数から割り出されているのだろうけど、今回使用しているCore i7 860だと、管理が始まる8セッションは少し遅すぎるのではないかと感じる。実際4セッションでCPUは振り切れている。

このときはキューイング管理は実装されるCPU数で決められると思ってたけど、db_file_multiblock_read_countが関係する。

今度は、db_file_multiblock_read_countを32->128と、当初の倍に増やしてみる：
そして、CPUもほぼ振り切れている状況に戻った

最後に、
DWHシステムでは、In-Memory Parallel Queryは「どんなことがあっても使いたい！」一番魅力的な機能です。
でも全てのデータをBUFFER_CACHEに乗せる事は物理的に難しいのでParallel Queryで補完する。それが理想形です。だから、前回のブログで大容量192GBメモリー搭載可能　System-Xマンのコマーシャル映像を載せたのです。
しかし、、、parallel_degree_policy=auto だけがIn-Memory PQを制御する指定で、CPUが振り切れないように制御する「キューイング管理」がどのタイミングで働くかが良く解りません。