[pgsql-jp: 29829] Re: SELECTプロセスの自動消去は出来ませんか？

[mkoban ＠ momijic.office.ne.jp]

お疲れ様です。小林と言います。

●ピンポイントではないです。

最近、似た現象が発生しました。(RedHat8.0/PostgreSQL7.3.1/tomcat4.1.18)
postgres: xxx db_xxx X.X.X.X idle in transaction
postgres: xxx db_xxx X.X.X.X SELECT waiting
postgres: xxx db_xxx X.X.X.X SELECT waiting
:

[pgsql-jp: 29242]からのスレッドを参考にLockしているテーブルを特定しまし
た。「in transaction」のスレッドが確か「AccessExclusiveLock」してて、
「SELECT waiting」のスレッドは「AccessShareLock」待ちの状態でした。

PostgreSQLの設定でLock待ちのタイムアウトの設定はできるかなと思って探した
のですが見つかりませんでした。

大元の原因である「in transaction」でLockを解除しないプログラムを見直した
ところ、transactionに入ったあと、（バグですが）ある条件で無限ループに陥
るようで、そちらの対応を施すことにより同現象は発生しなくなりました。（な
くなったようです．．．）

と、言うことで「in transaction」のまま「commit/rollback」しない原因を
（PostgreSQLのログやLockしているテーブルなどから）探すしかないのかなーな
んて思いました。「SELECTプロセスの自動消去」の方法は分からずです。（私の
場合．．．内緒ですが．．．頭に来てkillしてしまいました。）

あんまり役立ちそうでもないですね．．．でも少しでもお役に立てれば幸いです。

よろしくお願いします。

in "[pgsql-jp: 29822] Re: SELECTプロセスの自動消去は出来ませんか？" "Iso, 
Toshitaka" <Toshitaka.Iso ＠ hp.com> [Thu, 8 May 2003 20:07:11 +0900] 
wrote:

---- snip ----
>SELECTのプロセスだけでなく、idle in transactionの状態のものがCPUを多く使っている
>ことが分かりました。
>
>PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
>7869 postgres  11   0  150M 150M  148M R       71.9   3.9       7:36   postmaster
>
>[ServerName]$ ps auxww | grep 7869
>postgres  7869  2.8  3.9 165880 153712 ?     S    15:35   7:43 postgres: postgres DBNAME XX.XX.
>XX.XX idle in transaction
>
>このような現象が起きた事がある方、対処法をご存知の方、ぜひともご教授下さい。

---- snip ----

>> Web上で検索中にIEの×ボタンを押した場合、
>> 以下のようにSELECTのプロセスが残ってしまいパフォーマンスに影響が出てしまっています。
>> 
>> >> ps auxw | grep SELECT
>> postgres 18824  5.9  3.9 165328 153564 ?     S    13:13  12:52 postgres: postgres DB01 XX.XX.
>> XX.XX SELECT

---- snip ----

>> この残ってしまっているSELECTプロセスを自動的に消去することは出来ないのでしょうか？
>> PostgreSQLの設定で出来なければ違う方法でやられている方がいらしたらご教授いただけたら幸いです。

---- snip ----

-- 
M.Kob