Oracle Real Application Clusterの検証 その9

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

— 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の検証 ~その5~>参照”
これらに関する、統計情報に何か違いはあったのでしょうか。

これについては、来週お話しましょう。

当めるまがライターの”ちょびひげ”は実は宇宙人らしい 茅ヶ崎にて