[pgsql-jp: 27895] メモリリークについて
I26391_Sugiura ＠ aisin-aw.co.jp
I26391_Sugiura ＠ aisin-aw.co.jp
2002年 11月 8日 (金) 10:05:41 JST
はじめまして。
杉浦と申します。
最新案定版7.2.3を用いて、メモリリークの検証を行いました。
更新系のSQLを実行する度に、１M程度のメモリリークが発生し、
やがてフリーメモリを食いつぶす事がわかりました。
メモリリークの問題に対応する良い方法をご存知の方がいらっしゃいましたら
教えていただけないでしょうか？
postgres-7.2.3 メモリリーク検証
１．検証内容
レコード追加、レコード更新、レコード参照、レコード削除処理について
psqlを用いてSQLを実行し、サーバーリソース状況を確認する
２．検証環境
OS： RedHat7.2
CPU： １GHz（Pentium4）
Mem： 512M
HD： 30GHz
DB : postgres-7.2.3tar.gz
３．検証方法
(1)下記SQLを実行してテーブルを作成
create table schedule (
UNIQUECODE serial,
USER_NAME text,
USES text,
EFFECT text,
START_TIME timestamp,
END_TIME timestamp
);
(2)レコード挿入
(1)で作成したテーブルにレコード3000件を挿入し"vacuum schedule"を実行する
レコード挿入＋バキューム”の前後でサーバーリソースを確認する
(3)レコード更新
(2)で挿入したレコードを3000件更新し"vacuum schedule"を実行する
レコード更新＋バキューム”の前後でサーバーリソースを確認する
(4)レコード参照
(3)で更新したレコードの検索を実行する
レコード参照の前後でサーバーリソースを確認する
(5)レコード削除
(3)で更新したレコードを3000件削除し、"vacuum schedule"を実行する
レコード削除＋バキュームの前後でサーバーリソースを確認する
(6)上記(2)〜(5)を1000回連続して行い、処理前後のサーバーリソースを確認する
３．検証結果
(1)．データ挿入時(insert)の検証結果
a.挿入前のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs
us sy id
0 0 0 0 420136 3904 37912 0 0 0 0 127 8 0
0 100
ｂ．SQL実行10分後のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 419028 3908 38992 0 0 0 0 127 6 0 0
92
◆約１Mバイトリークする
(2)．データ更新時（update)の検証結果
a.挿入前のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 419028 3908 38992 0 0 0 0 127 6 0 0
100
ｂ．SQL実行10分後のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 417756 3908 40232 0 0 0 0 127 6 0 0
83
◆約１．５Mバイトリークする
(3)．データ参照時（select）の検証結果
a.挿入前のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 417756 3908 40232 0 0 0 0 128 12 0 0
100
ｂ．SQL実行10分後のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 417752 3908 40236 0 0 1 0 136 40 1 3
96
◆データ参照ではリークは見られない
(4)．データ削除時（delete）の検証結果
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 417752 3908 40236 0 0 0 0 128 14 0 0
100
ｂ．SQL実行10分後のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 417576 3908 40388 0 0 0 0 127 12 0 0
95
◆約200Kバイトリークする
(5)．データの挿入、更新、参照、削除処理を1回とし、これを連続1000回行った場合
の検証結果
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 425164 3752 33276 0 0 0 0 130 7 0 0
100
ｂ．SQL実行10分後のサーバーリソース
1秒毎のリソースを５分間取得（vmstat 1)し、平均した値
procs memory swap io system
cpu
r b w swpd free buff cache si so bi bo in cs us sy
id
0 0 0 0 86532 46264 243432 0 0 0 0 127 8 0 0
100
◆約338Mバイトリークする
４．検証結果から
insert,update,select,deleteの一連の操作の中で、おおよそ２．７Kバイトのメモ
リリークが発生した。
また、挿入、更新、参照、削除の一連の処理を連続１０００回行った結果、
３３８Mバイトのメモリリークが確認された。
データを更新するタイプのデータベースでは、insert,update,delete処理を行うた
びに
メモリリークが発生し、やがてサーバーのフリーメモリを全て使ってしまう。
postgres-7.2.3を用いたデータベースシステムでは、定期的にサーバーのリブート
を行わないと
サーバーのフリーメモリがなくなる為、DBサーバーに障害が発生すると予想され
る。
----
Hiroaki Sugiura
pgsql-jp メーリングリストの案内