Oracle Real Application Clusterの検証 その３
＜Oracle Real Application Clusterの検証 ～その３～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
さてシングルインスタンス下で最適化したアプリケーションを、そのままRAC
環境に移行しても、処理性能がスケーラブルどころかむしろ遅くなってしまう
可能性があることをお話しました。
どこに原因があったのでしょうか。
Oracleの動的パフォーマンスビューにV$SYSTEM_EVENTというビューがありま
す。このビューからシステムの待機イベントの情報が取得できそうです。
このビューから待機時間を取得するためには、初期化パラメータの
“TIMED_STATISTICS”をTRUEに指定する必要がありますが、Oracle 9i Release
2からは”TRUE”がデフォルトなので、時間情報もデフォルトのままで取得可能
です。
また、このビューは合計の待機時間が表示されるので、対象の処理を行う前
後の差分を取得することにより詳細に調査が出来ます。
先週お話した環境で、上記の値はどのようになっていたのでしょか。
(先週の資料)
CASE INSTANCE NO SESSIONs EPS(※1) TPS(※2)
=======================================================
01 1 237 16,083 732.3
-------------------------------------------------------
02 1 256 5,453
2 256 5,362
----------------------------------------------
Total 512 10,815 489.4
-------------------------------------------------------
V$SYSTEM_EVENTの情報
CASE INSTANCE NO EVENT WAIT数 WAIT時間(sec)
=================================================================
01 1 log file sync 1,763,899 422,800 << (1)
latch free 456,638 38,245
buffer busy waits 244,583 16,821
enqueue 122,109 12,221
-----------------------------------------------------------------
02 1 enqueue 2,367,703 410,303 << (2)
buffer busy waits 3,025,078 314,120 << (3)
buffer busy global
cache 1,736,016 206,586 << (3)
global cache busy 1,042,919 95,160
latch free 4,551,655 75,086
--------------------------------------------------------
2 enqueue 2,341,917 408,503 << (2)
buffer busy waits 3,034,419 321,680 << (3)
buffer busy global
cache 1,748,311 213,001 << (3)
global cache busy 968,529 85,302
latch free 4,638,862 73,170
-----------------------------------------------------------------
CASE01では、”log file sync”イベントのWAIT時間がもっとも多くなっていま
す。(表中(1)) “log file sync”イベントは、DBWRがデータベースバッファ上
のダーティーブロックをディスク上に書き出す際、ログバッファにある更新
データをオンラインREDOログファイルへ書き出すイベントです。
このイベントは、トランザクション中にあまりコミットが実行されていない
場合に多く見られます。このイベントで待ちがたくさん発生しているシステ
ムをお持ちの方は、ちゃんとコミットしましょうね。
では、RACの各インスタンスで処理を実行したCASE02ではどうでしょう。
各インスタンスの最上位に”enqueue”イベントがきています。(表中(2))
どのエンキューの取得に時間がかかったのかは、V$ENQUEUE_STATビューを見
るとわかります。
CASE02では、特に”TX”エンキューが非常に高いことがわかりました。
********************************************************
EQ_TYPE TOTAL_REQ TOTAL_WAITS WAITTIME (sec)
--------------------------------------------------------
TX 4,682,405 1,892,191 419,433
HW 30,123 27,898 3,011
SQ 283 172 14
********************************************************
しかし、”enqueue”イベントだけに、時間がかかっているわけではないようで
す。”buffer busy waits”および”buffer busy global cache”も他のイベント
と比較しても待ち時間がかなり大きくなっています。(表中(3))
これに関しても”enqueue”と同様、どのバッファに待ちが発生していたかを確
認してみましょう。
Oracle 9i Release 2では、V$SEGMENT_STATISTICSビューから各オブジェクト
の統計情報が取得できます。ここから、バッファ上の待ち回数”buffer busy
waits” や、RAC環境で確認できるINTER CONNECT経由のブロック転送量
“global cache current blocks served” などの情報が取得できます。
このビューを利用して、バッファ待ち回数の多いオブジェクトを特定してみま
す。すると、CASE02では以下のような結果となりました。
******************************************************** (buffer busy waits) OBJECT TYPE WAIT回数 --------------------------------------- IDX_LOGTBL1 INDEX 2,445,422 IDX_LOGTBL2 INDEX 2,074,474 LOGTBL2 TABLE 76,123 LOGTBL1 TABLE 37,154 PK_SESINFO INDEX 32,102 ********************************************************
ログ系のインデックスで特にWAIT回数が多いですね。
このログ系のテーブルは、実はトランザクションログを残すテーブルですが、
日付や、順序などをインデックス項目にした場合、同一ブロックへの更新
（追加）が集中することはすでにご承知のとおりです。
（バックナンバー “トランザクションエントリに関する検証 8″参照のこと(※)）
とくに、ログ系のテーブルであれば、データの検索を考えて日付をキーにする
ケースも多々あることでしょう。
ではこのテーブルのインデックスにはどんな列が指定されているかと言うと
、、、、おっとやっぱり登録日時だ。つまり、日付時刻データをINDEXとして
INSERTするため、ブロックの競合が発生していることが予想されます。(※)
先ほどと同様に、V$SEGMENT_STATISTICSからオブジェクトの情報を取ってみ
ます。今度は、”ITL waits”です。(“ITL”=”トランザクションエントリ”)
******************************************************** (ITL waits) OBJECT TYPE WAIT回数 --------------------------------------- IDX_LOGTBL1 INDEX 1,532 IDX_LOGTBL2 INDEX 1,210 PK_SESINFO INDEX 33 IDX_LOGTBL3 INDEX 1 PK_MSINFO INDEX 1 ********************************************************
やはりログ系のテーブルでトランザクションエントリの待ちが発生しています。
と言うことは、インデックスのトランザクションエントリの競合が発生すると、
テーブルの場合と違い待ちが発生してしまいます。(※)
実は、トランザクションエントリの待ちは、CASE01(IDX_LOGTBL1で6回程度)
でもおきています。しかしその数はけた違いに小さい値です。CASE01と02では
合計のSESSION数が違うことにお気づきの方もおられるとおもいます。CASE01
と比較するために、両インスタンスから128SESSIONで接続し同時接続数の合計
をほぼ同じにして、同様の検証を行ってみました。
その結果は以下のとおりです。
******************************************************** (ITL waits) OBJECT TYPE WAIT回数 --------------------------------------- IDX_LOGTBL1 INDEX 524 IDX_LOGTBL2 INDEX 124 PK_SESINFO INDEX 16 ********************************************************
トランザクションエントリの待ちはCASE02と比較するとかなり小さな値です。
でも、CASE01と比較すると、約90倍にもなります。
なぜ、CASE02ではなぜ”buffer busy waits”や、”ITL waits”が多くなるのでし
ょうか。
続きはまた来週。
なーがーぐつでー でかけよ おぅ！！ でも 雨上がりの茅ヶ崎にて