共有プール領域に関する検証 その10

<共有プールに関する検証 その10> ペンネーム ダーリン

– 続・共有プールのフラグメンテーション --

前回は共有プールの断片化の様子をおってみた。
今回はその中でも”free memory”について、断片化の様子をみてみることにしよう。

前回X$KSMSP表から以下のような断片化の様子を見ることが出来た。

*********************************************************************

KSMCHCOM              CHUNK       RECR    FREEABL        SUM
---------------- ---------- ---------- ---------- ----------
(※1)
free memory              98                         32525012
(※2)
free memory           16015                         13904108


※1:インスタンス起動直後
※2:処理経過後

*********************************************************************

“free memory”についても”CHUNK”の値が増加していることから、断片化が進
んでいることがわかる。

“free memory”で示される領域にオブジェクト(カーソル等を含む)をロード
する際に、まとまった領域が確保できないと、追い出しが発生するが、では
“free memory”のまとまった領域はどの位の大きさだろうか。
これは、各サイズ(”KSMCHSIZ”)の最大のものがどれくらいかを見ればよいだ
ろう。

SQL> select max(KSMCHSIZ),KSMCHCOM from x$ksmsp
  2 group by KSMCHCOM
  3 order by max(KSMCHSIZ) desc;

(※1)
MAX(KSMCHSIZ) KSMCHCOM
------------- ----------------
      3981312 free memory
      3977416 permanent memor
       157196 character set o
        44372 character set m

     <以下、省略>
           :
           :

(※2)
MAX(KSMCHSIZ) KSMCHCOM
------------- ----------------
      3977416 permanent memor
       212916 free memory
       157196 character set o
        44372 character set m

     <以下、省略>
           :
           :

※1:インスタンス起動直後
※2:処理経過後

(当然といえば当然だが)”free memory”は最初は大きかった。(約3.9MB)
徐々に断片化が進んだ結果、大きいチャンクでも200KB程度となっている。

インスタンス起動直後の”free memory”について確認してみる。

SQL> select KSMCHSIZ,KSMCHCOM from x$ksmsp
  2  where KSMCHCOM = 'free memory'
  3  order by KSMCHSIZ;

           :
       <省略>
        84 free memory
        88 free memory
        88 free memory

  KSMCHSIZ KSMCHCOM
---------- ----------------
      1584 free memory
      2648 free memory
      2888 free memory
    212916 free memory
       <中略>
    212916 free memory
   2243264 free memory    <-----(※3)
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory

99行が選択されました。    <-----(※4)

ここでSQL文が実行されると、徐々に”free memory”の断片化がはじまる。

実行したSQL文

SQL> select * from dba_source;

SQL> select KSMCHSIZ,KSMCHCOM from x$ksmsp
  2  where KSMCHCOM = 'free memory'
  3  order by KSMCHSIZ;

           :
       <省略>
        84 free memory
        88 free memory
        88 free memory
      1484 free memory

  KSMCHSIZ KSMCHCOM
---------- ----------------
    212916 free memory
       <中略>
    212916 free memory
   1986928 free memory    <-----(※3)
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory

107行が選択されました。    <-----(※4)

SQL> select KSMCHSIZ,KSMCHCOM from x$ksmsp
  2  where KSMCHCOM = 'free memory'
  3  order by KSMCHSIZ;

           :
       <省略>
        84 free memory
        88 free memory
        88 free memory
      3148 free memory

  KSMCHSIZ KSMCHCOM
---------- ----------------
      6480 free memory
    212916 free memory
       <中略>
    212916 free memory
   1967808 free memory    <-----(※3)
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory
   3981312 free memory

108行が選択されました。    <-----(※4)

(※3)で示されるチャンクのサイズが徐々に減少し、”free memory”の領域が
取得されている様子が、また、X$KSMSP表のレコード数が増えている(※4)こ
とから、断片化したチャンク自体が増加していることがわかる。

かなり駆け足になってしまったが、共有プールの断片化の様子がおわかりいた
だけたであろうか。

フラグメントが多発した場合、これをを解消するには、以下のSQLを実行すれ
ばよい。

SQL> alter system flush shared_pool;

無論、大きなオブジェクトはkeepするなどして、再読み込み自体を減らすこと
が一番有効である。

なお”共有プールに関する検証”は今回で終了するが、引き続き検証した結果は、
いずれ改めてこの場で報告したい。

以上 秋の気配が漂い始める 茅ヶ崎にて