ASSMに関する検証 その10

<ASSMに関する検証 その10>
ペンネーム: サマー・リーフ

▼前回までのおさらい

前回は、FREELIST管理におけるテーブルの storage句の”freelist groups”パ
ラメータを調整して各セグメント管理方法の違いを確認してきました。
“buffer busy waits”待機イベントの統計をもとに比較し、バッファブロック
の競合を考察しました。

さて、”freelist groups”パラメータとは??

複数インスタンスからフリーリストへのアクセス競合を軽減する為のパラメー
タでした。

従って、複数インスタンスで構成される Real Apllication Cluster(以降、
RACと表記)環境で検証をしました。

前回の考察と違う着目点にて、各検証パターンを比較していきましょう。

■環境

OS :Red Hat Enterprise Linux ES release 4
DB :Oracle10g EE Release 2( 2 NODE RAC)

■検証

↓↓↓ 検証の前提、パターンは、バックナンバーを参照してください。 ↓↓

<ASSMに関する検証 その9>
https://www.insight-tec.com/mailmagazine/ora3/vol339.html

↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

●各検証パターンで作成したテーブルの設定値

(1)自動セグメント領域管理(ASSM)
(2)FREELIST管理 1
(3)FREELIST管理 2

     OWNER  TABLE_NAME      FREELISTS  FREELIST_GROUPS
     ------ --------------- ---------- ---------------
     ITI1   SUMMER_LEAF                                 ←(1)
     ITI2   SUMMER_LEAF             1               1   ←(2)
     ITI2   SUMMER_LEAF_2           3               2   ←(3)

●グローバルキャッシュ関連(”gc* ***”)の待機イベントと実行時間

前回も触れました RACについて、おさらいします。

RAC環境では、複数のインスタンスが単一のデータベースにアクセスする構
成なので、キャッシュの一貫性を保つためにインスタンス間でキャッシュ
の内容(ブロック)を転送します。

この仕組みは、”グローバルキャッシュサービス”という RACの機能が司り
ます。
また、キャッシュの内容(ブロック)の転送を”キャッシュフュージョン”
と呼ばれる機能が実際に行います。

従って、グローバルキャッシュ関連(”gc* ***”)の待機イベントの統計か
らインスタンス間でキャッシュの要求、転送によるブロック競合を確認す
ることができます。

(1)自動セグメント領域管理(ASSM)

・ノード1では、”gcs log flush sync”が待機回数、待機秒数ともに一番
高い値となりました。

この待機イベントは、ログバッファの内容をREDOログファイルへ書き出
す際に待ちが発生したときにカウントされます。

キャッシュフュージョンが、キャッシュブロックを要求したノードへ更
新ブロックを転送する前に、転送する側のノードでログバッファの内容
をREDOログファイルへ書き出す動作をします。

従って、ノード1からノード2へ、更新ブロックを転送しているために
待機が発生したと考えられます。

・ノード2では、”gc cr block busy”が待機秒数で高い値となっています。

ノード1からノード2へ更新ブロックを転送する際に、ノード1で発生
する”gcs log flush sync”待機イベントが影響して、ブロック競合を起
こし待機が発生したと考えられます。

     [ノード1]
                                                          Avg
                                       %Time Total Wait   wait  Waits
     Event                     Waits   -outs   Time (s)   (ms)   /txn
     ------------------------- ------- ------ ---------- ------ ------
     gcs log flush sync         1,354     85         24     18    0.0
     gc buffer busy               155      2         13     86    0.0
     gc current block busy         38      3         10    263    0.0
     gc current block 2-way       154      1          4     26    0.0

     ▼実行時間

       セッション(1) → Elapsed: 00:01:35.09
       セッション(2) → Elapsed: 00:01:38.83
       セッション(3) → Elapsed: 00:01:39.10
       平均          → Elapsed: 00:01:37.34
     [ノード2]
                                                          Avg
                                       %Time Total Wait   wait  Waits
     Event                     Waits   -outs   Time (s)   (ms)   /txn
     ------------------------- ------- ------ ---------- ------ ------
     gc cr block busy              45      0         26    568    0.0
     gc buffer busy               190      5         18     97    0.0
     gc current block busy         37      8         12    334    0.0
     gcs log flush sync           553     77         11     21    0.0
     gc current block 2-way       766      0         10     13    0.0

     ▼実行時間

       セッション(1) → Elapsed: 00:01:23.04
       セッション(2) → Elapsed: 00:01:38.83
       セッション(3) → Elapsed: 00:01:41.96
       平均          → Elapsed: 00:01:34.61

(2)FREELIST管理 1

FREELIST管理、且つ フリーリストグループをデフォルトの 1 とした場
合、自動セグメント領域管理(ASSM)と比較すると、待機回数、待機時
間 共に大きな値になっています。

従って、ノード1からノード2へ、頻繁に更新ブロックを転送している
ために発生した待機が影響して自動セグメント領域管理(ASSM)に比べ
約1.8倍の処理時間となりました。

     [ノード1]
                                                          Avg
                                       %Time Total Wait   wait  Waits
     Event                     Waits   -outs   Time (s)   (ms)   /txn
     ------------------------- ------- ------ ---------- ------ ------
     gc buffer busy             8,547      0        164     19    0.0
     gcs log flush sync         6,081     45         78     13    0.0
     gc current block busy      1,144      0         76     67    0.0
     gc current multi block     1,741      0         30     17    0.0
                      request
     gc current block 2-way     1,787      0         11      6    0.0

     ▼実行時間

       セッション(1) → Elapsed: 00:02:26.80
       セッション(2) → Elapsed: 00:02:33.19
       セッション(3) → Elapsed: 00:03:11.33
       平均          → Elapsed: 00:02:43.44
     [ノード2]
                                                          Avg
                                       %Time Total Wait   wait  Waits
     Event                     Waits   -outs   Time (s)   (ms)   /txn
     ------------------------- ------- ------ ---------- ------ ------
     gc buffer busy             9,323      0        202     22    0.0
     gcs log flush sync         6,045     45         76     13    0.0
     gc current block busy      1,067      0         74     69    0.0
     gc current multi block       936      0         33     35    0.0
                 request                
     gc current block 2-way     2,019      0         14      7    0.0
     gc current grant busy         88      0          3     31    0.0

     ▼実行時間

       セッション(1) → Elapsed: 00:03:10.50
       セッション(2) → Elapsed: 00:03:10.50
       セッション(3) → Elapsed: 00:03:10.82
       平均          → Elapsed: 00:03:10.60

(3)FREELIST管理 2

FREELIST管理、且つ フリーリストグループをインスタンス数に合わせて
調整した結果をみると、待機回数、待機時間共に検証パターンで一番小
さい値になりました。

しかし、自動セグメント領域管理(ASSM)に比べ 約1.2倍 長い処理時間
となりました。

前回、考察した”buffer busy waits” 待機イベントと”gc* ***” 待機イ
ベントの統計情報からしても、フリーリストグループを調整した方が効
率よく処理されているように見えましたが、実行時間が長くなる原因が
あるようです。

     [ノード1]
                                                          Avg
                                       %Time Total Wait   wait  Waits
     Event                     Waits   -outs   Time (s)   (ms)   /txn
     ------------------------- ------- ------ ---------- ------ ------
     gc current block 2-way       579      1          6     11    0.0
     gc current grant busy         97      0          6     61    0.0
     gc cr block busy               8      0          1    127    0.0
     gc buffer busy                 5     20          1    199    0.0
     gcs log flush sync            49     90          1     18    0.0

     ▼実行時間

       セッション(1) → Elapsed: 00:01:55.81
       セッション(2) → Elapsed: 00:01:59.09
       セッション(3) → Elapsed: 00:01:59.84
       平均          → Elapsed: 00:01:58.58
     [ノード2]
                                                          Avg
                                       %Time Total Wait   wait  Waits
     Event                     Waits   -outs   Time (s)   (ms)   /txn
     ------------------------- ------- ------ ---------- ------ ------
     gc current grant busy         96      0          3     35    0.0
     gc current block 2-way       431      0          2      5    0.0
     gcs log flush sync            57     72          1     24    0.0

     ▼実行時間

       セッション(1) → Elapsed: 00:01:51.95
       セッション(2) → Elapsed: 00:01:54.19
       セッション(3) → Elapsed: 00:01:54.37
       平均          → Elapsed: 00:01:53.50

[まとめ]

グローバルキャッシュ関連(”gc* ***”)待機イベントの統計から以下の順で
ブロックの競合が、多く発生する結果となりました。

(2)FREELIST管理、且つ デフォルト値(FREELIST 1、FREELIST GROUPS 1)

(1)自動セグメント管理(ASSM)

(3)FREELIST管理、且つ FREELIST 3、FREELIST GROUPS 2

前回の検証結果の考察と同様に、FREELIST管理、且つ セグメント作成時に
Storage句でパラメータを調整する方が、RAC環境で発生しがちなブロック競合
を減らすことができそうです。

が・・・・

検証結果からは、ブロック競合によって発生する待機イベントが一番少なくな
っているにもかかわらず、なぜ実行時間が遅くなってしまったのでしょうか?

環境による誤差か?
何か、他に原因が?

謎を残して、次回に持ち越すのは心苦しいですが、
今日はここまで。

もうすぐ、梅雨入り・・・
“つゆいり”って変換すると”入梅”!知ってました? 茅ヶ崎より