共有プール領域に関する検証 その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するなどして、再読み込み自体を減らすこと
が一番有効である。
なお”共有プールに関する検証”は今回で終了するが、引き続き検証した結果は、
いずれ改めてこの場で報告したい。
以上 秋の気配が漂い始める 茅ヶ崎にて