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

投稿日: 2002年9月25日

＜共有プールに関する検証　その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”）の最大のものがどれくらいかを見ればよいだ
ろう。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
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”について確認してみる。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
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文

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
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を実行すれ
ばよい。

1
SQL> alter system flush shared_pool;

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

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

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