Oracle Real Application Clusterの検証 その９
＜Oracle Real Application Clusterの検証 ～その９～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
さて、先週はチューニング対象としたインデックスに対する変更を実施し、
また、そのインデックスを使う検索側にもインデックス・スキップ・スキャン
を使用するように対応をしました。
実際のチューニングの現場では、検証期間や、そもそも検証出来る環境が確保
できない場合が多く、しかし時々刻々とカットオーバーが迫ってきます。
今回のように、確認できる時間と環境が確保できたことに感謝感謝です。
そんな現場の声も届かずに、文句をのたまう人々に一言、、
「トラブルは会議室でおきてるんじゃない！！ 現場で起きてるんだ！！」
現場はこちら –>> https://www.insight-tec.com/
さあこれで、登録処理、検索処理ともに、インデックスの変更ができました。
では、その効果の程はいかがなのもでしょうか。
まず、もともとの数値をもう一度見てましょう。
********************************************************
(チューニング前)
CASE INSTANCE NO SESSIONs EPS TPS
=======================================================
01 1 237 16,083 732.3
-------------------------------------------------------
02 1 256 5,453
2 256 5,362
----------------------------------------------
Total 512 10,815 489.4
-------------------------------------------------------
Scalability = 0.67
********************************************************
当初、RAC構成にするとシングルインスタンス状態のときと比較して、0.67倍
と下回ってしまいました。
そこで今回のチューニングを行ったわけですが、ではその成果はと言えば、
こんな感じです。
********************************************************
(チューニング後)
CASE INSTANCE NO SESSIONs EPS TPS
=======================================================
01 1 237 16,083 732.3
-------------------------------------------------------
03 1 256 10,746
2 256 13,365
----------------------------------------------
Total 512 24,111 1079.4
-------------------------------------------------------
Scalability = 1.47
********************************************************
いかがでしょうか。インデックスひとつのチューニングで、処理性能 2倍以
上です。正確に言うと、同じようなインデックスがもうひとつあったので、
チューニング対象のインデックスは2個ですが。
では、これまで着目してきた統計情報にはどのような違いが出てきているの
でしょうか。(以下はいずれもRACの1つのインスタンスの情報です。)
まずは、オブジェクトごとのWaitに関してみてみましょう。
******************************************************** (チューニング前) OBJECT TYPE WAIT回数 --------------------------------------- IDX_LOGTBL1 INDEX 1,532 << (1) IDX_LOGTBL2 INDEX 1,210 << (2) PK_SESINFO INDEX 33 IDX_LOGTBL3 INDEX 1 PK_MSINFO INDEX 1 --------------------------------------- (チューニング後) OBJECT TYPE WAIT回数 --------------------------------------- PK_SESINFO INDEX 696 PK_MSINFO INDEX 54 PK_MSINFO_MA INDEX 38 IDX_MSINFO INDEX 6 --------------------------------------- ********************************************************
******************************************************** (チューニング前) OBJECT TYPE WAIT回数 --------------------------------------- IDX_LOGTBL1 INDEX 2,445,422 IDX_LOGTBL2 INDEX 2,074,474 LOGTBL2 TABLE 76,123 << (3) LOGTBL1 TABLE 37,154 << (4) PK_SESINFO INDEX 32,102 --------------------------------------- (チューニング後) OBJECT TYPE WAIT回数 --------------------------------------- PK_MSINFO INDEX 336,430 PK_SESINFO INDEX 322,564 PK_MSINFO_MA INDEX 117,048 LOGTBL2 TABLE 106,772 << (3) LOGTBL1 TABLE 57,724 << (4) --------------------------------------- ********************************************************
まず、ログ系のインデックスのWaitがすっかり姿を消していることがわかり
ます(1)(2)。ログ系のテーブルの”Buffer Busy Waits”がやや増えているよう
ですが、トランザクション量自体が増えているので、それに伴って増えたと
考えられます(3)(4)。
今回掲げた
=======================================================
“buffer busy waits”が発生している、ログ系のインデックスに関して
「インスタンス間での競合を減らそう。」
=======================================================
と言う目的に対して、今回のチューニングが明らかに効果を発揮したといえ
るでしょう。
イベント統計に関しては、どうなっているのでしょうか。
********************************************************
(チューニング前)
INSTANCE NO EVENT WAIT数 WAIT時間(sec)
-----------------------------------------------------------------
2 enqueue 2,341,917 408,503
buffer busy waits 3,034,419 321,680
buffer busy global cache 1,748,311 213,001
global cache busy 968,529 85,302
latch free 4,638,862 73,170
-----------------------------------------------------------------
(チューニング後)
INSTANCE NO EVENT WAIT数 WAIT時間(sec)
-----------------------------------------------------------------
2 log file sync 3,146,732 629,080
enqueue 802,320 203,810
buffer busy waits 715,314 71,804
buffer busy global cache 351,148 51,782
latch free 892,286 50,836
********************************************************
トータルのWAIT時間もやや減少しているようですが、なにより、”enqueue”と
“buffer busy ..”のWAIT数もケタ違いに減少しています。
変わって、チューニング後のWAITイベントNO.1は”log file sync”になりまし
た。このイベントが発生するパターンは2通り考えられます。ここでは詳細に
ついて述べませんが、コミットがあまり発行されていない環境か、もしくは、
反対にかなり頻繁にコミットが発行されている環境で起こりえます。後者の
場合、かなりの数のトランザクションをこなしているともいえますが。
さて、この統計情報を見る限りは、”buffer”の(表現を変えれば、オブジェク
トの)待ちがトータルとしてもかなり減少したと判断できます。
インデックスをチューニングすることで、他にしわ寄せがきて、トータルで
のWaitが大きくなっていないことが確認できればOKでしょう。
まあ、”log file Sync”にしわ寄せが来てるじゃないか。といえなくもないの
ですが、これは、処理性能が上昇したために表面化したと言うのが実際です。
今回のチューニングが間違った方向に来たわけではないので、あしからず。
次のチューニングポイントが見えてきたということは、ステップがひとつ進
んだと言うことです。前向きに捕らえましょう。
さて、RAC環境では “GCS(グローバルキャッシュサービス)がインスタンス間
におけるデータの整合性を保つ役割を担っていることをお話したことがあり
ます。
“＜Oracle Real Application Clusterの検証 ～その５～＞参照”
これらに関する、統計情報に何か違いはあったのでしょうか。
これについては、来週お話しましょう。
当めるまがライターの”ちょびひげ”は実は宇宙人らしい 茅ヶ崎にて