Oracle Real Application Clusterの検証 その10

<Oracle Real Application Clusterの検証 ~その10~>
ペンネーム ダーリン

— 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”の処理時間の短縮と
言う形であらわれていました。それは”エンキュー待ち”の解消と言う比較的
イメージしやすいものです。

来週は、今回のチューニング作業をおさらいしてみましょう。

どうも腰が痛いとおもったらヘルニアだと言われた 茅ヶ崎にて