Oracle Real Application Clusterの検証 その１０
＜Oracle Real Application Clusterの検証 ～その１０～＞
ペンネーム ダーリン
— RAC環境でのチューニング —
さあ、RACのチューニングもいよいよ大詰めです。
先週、インデックスのチューニングを実施したところ、スケーラビリティー
が大幅に向上したことを確認しました。チューニングの方向が正しかったこ
とが確認できてほっとしています。
また、これを裏付けるように、チューニング対象にしたインデックスの
“ITL Waits”や、”Buffer Busy Waits”が大幅に減少していることを
V$SEGMENT_STATISTICSビューで確認しました。
さらに、V$SYSTEM_EVENTビューからはシステム全体のWAIT状況を確認しました。
“enqueue”や、”buffer busy waits”、”buffer busy global cache”など”buffer”
関連の待ちが減少していました。
さて、RAC特有の”GCS(グローバルキャッシュサービス)”と言うサービスがあ
ります。以前、お話させていただきましたが、インスタンスをまたがってデー
タの整合性を保つために重要な役割を担っているサービスです。
これについて、何か変化はあったのでしょうか。
**********************************************************
(チューニング前)
CASE01 CASE02 (instance 1)
----------------------------------------------------------
global cache convert time(※1) 2.3 22.9 (ms)
global lock get time(※2) 1.3 38.6 (ms)
(チューニング後)
CASE03 (instance 1)
----------------------------------------------------------
global cache convert time(※1) 39.3 (ms)
global lock get time(※2) 10.4 (ms)
※1 global cache convert time/global cache converts
※2 global lock get time/(global lock async gets+global lock sync gets)
**********************************************************
何か違いがあらわれているようですね。
話は少し飛びますが、以前”GCS”のお話をさせていただきましたが、実はRACを
構成するに当たりもうひとつ重要なサービスがあります。”GES(グローバルエ
ンキューサービス)”です。”global lock get time”は”GES”に関する統計情報
です。
“GES”は、インスタンス間をまたがったエンキュー情報を管理します。
例えば、自インスタンスで、とあるデータを更新中に、他インスタンスでその
テーブルをDROPされては困ります。そこで別のインスタンスで表ロックがかか
っている場合など、DDLを実行できないようにする必要があります。シングル
インスタンスの環境では普通に行っていることですが、RAC環境ではこれを
“GES”が担当します。ちなみに、”GES”の実体は”LMD”と言うサービス（と言う
かデーモン?）です。
さてさて、ではここから、何が読み取れるでしょうか。
チューニングの結果、”global cache convert time(※1)”の時間が増えて、
反対に”global lock get time(※2)”の時間が短くなっていますね。
んー。それだけかなぁ？ 何か今ひとつ見えてきませんね。
上記※1、※2はそれぞれ、1リクエストあたりの所要時間です。
そもそもリクエスト自体(※1や、※2の分母)の回数はどうなっているのでし
ょうか。 以下は、差分計算したV$SYSSTATの値そのままです。
******************************************************************* instance 1 チューニング (前 10ms) (後 10ms) ------------------------------------------------------------------- global cache convert time 969,075 1,604,022 global cache converts 423,314 408,262 global lock async gets 4,828 12,600 global lock sync gets 10,733,630 17,517,200 global lock get time 41,433,031 18,312,454 instance 2 ------------------------------------------------------------------- global cache convert time 920,928 1,386,120 global cache converts 392,841 394,132 global lock async gets 4,822 12,112 global lock sync gets 10,487,512 21,365,590 global lock get time 41,316,116 21,027,412 *******************************************************************
“global cache converts”のリクエスト自体は、あまり変わっていませんね。
しかしながら、実はトランザクション数が約2倍になっていることを考えれば、
実質、半分になっていると考えてよさそうです。
このあたりに、今回のインデックスチューニングの効果が現れているようです。
でも、処理に要した時間は延びている見たいですねぇ。
さて、もう一方の”global lock async/sync gets”はというと、こちらはあま
り変わりはありません。トランザクションの伸びと同様に回数も伸びています。
しかしながら、その所要時間はなんと、半分。トランザクションの伸びを考
慮すると約1/4になっています。
もう少し見てみましょう。
何か見えてきませんか。。。。。
どうでしょう……
まだ見えてきませんか ~~~~~~~~~~
えっ。やっとみえましたか！！
そうなんです。”global cache converts”と、”global lock sync gets” では、
リクエストされている回数に【けた違い】の差があるんです。
最初っから単位リクエストあたりの所要時間を見ようとしていたため、その
違いに気がつきませんでした。
それぞれの割合を見てみると一目瞭然です。
******************************************************************* instance 1 チューニング (前 10ms(%)) (後 10ms(%)) ------------------------------------------------------------------- global cache convert time 969,075( 2.1) 1,604,022( 6.4) global cache cr block build time 2,296( 0.0) 1,950( 0.0) global cache cr block flush time 22,658( 0.0) 679,202( 2.7) global cache cr block send time 110,612( 0.1) 99,074( 0.4) global cache cr block receive tim 521,939( 1.1) 1,531,250( 6.2) global cache current block flush 86,058( 0.2) 297,198( 1.2) global cache current block pin ti 382,498( 0.8) 300,052( 1.2) global cache current block send t 61,183( 0.1) 130,462( 0.5) global cache current block receiv 2,417,464( 5.2) 1,539,686( 6.2) global cache get time 182,562( 0.4) 410,640( 1.7) global lock convert time 357( 0.0) 5,726( 0.0) global lock get time 41,433,031(89.7) 18,312,454(73.5) =================================================================== *******************************************************************
すごいですね。チューニングの有無を問わずWAITの大半が”global lock get
time”であることがわかります。また、チューニング後にもっとも減少して
いるWAITが、”global lock get time”であることもわかります。
ここでは”instance 1″を例にとっていますが、”instance 2″でもほぼ同様の
結果となっています。
先にも述べましたが”global lock get time”は”GES”の管理するイベントです。
“GES”の影響(負荷？)は大きいですね。
グローバルエンキュー・・・？、そういえば、チューニング後のエンキュー
の詳細を見ていませんでした。ちょっと確認してみましょう。（データ捨て
たかな？・・・・・・・・・・っと、あった、あった。）
こんな感じです。
******************************************************************* (チューニング前) instance 1 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 CF 7,634 292 11 TT 1,085 816 10 TA 324 320 4 US 335 123 0 (チューニング後) instance 1 EQ_TYPE TOTAL_REQ TOTAL_WAITS WAITTIME (sec) -------------------------------------------------------- HW 155,472 153,202 117,494 TX 5,469,420 250,862 54,910 SQ 3,482 2,904 470 PS 76 36 8 US 1,958 1,076 6 TA 454 24 0 *******************************************************************
エンキューの待ち時間が、”GES”の統計値の処理時間とよく一致しています。
どうも、”GES”の待ち時間のほとんどは、純粋にエンキュー待ちのようです。
（幾分前後していますが）
また、チューニングの結果、”TX”エンキューが減少していることがわかりま
す。
今回のチューニングでは、インデックスがインスタンス間を飛び交わないよ
うにすることが目的でした。これにより”GCS”の負荷が減少するのではないか
と考えていたのですが、その効果の大半は、実は、”GES”の処理時間の短縮と
言う形であらわれていました。それは”エンキュー待ち”の解消と言う比較的
イメージしやすいものです。
来週は、今回のチューニング作業をおさらいしてみましょう。
どうも腰が痛いとおもったらヘルニアだと言われた 茅ヶ崎にて