フレームワークとかはつかっておりません。
DBへのConnectionPoolなども行っておりません。
大量データのSQL(SELECT)を実行したときに、待ちきれないのでページを閉じると
そのままPostgreSQLへのセッションがKillするまで永久に残ってしまいます。
これをなんとか手動でkillしないでも消す方法はないものでしょうか。
たとえば、同じページが開かれたときにとある関数を実行すると消えるとか、
cronで監視して一定時間以上起動しっぱなしのpostgresのプロセスを消す方法とか。
Postgres.confをいじればいいよ。とか。
そのような対応策があったら教えてください。
No.2
2915
301
32pt
SELECT pg_cancel_backend(pid); でキル！
http://www.postgresql.jp/document/pg830doc/html/functions-admin....
あとは、どのようにして状態を得るか、また、どうのような状態なら、
消してしまうかという点ですが、参照系のシステムであるならば、
単純に pg_locksテーブル を見てpidを取得し、キルという流れで良いかもしれません。
このあたりの対応はシステムによりますので、ケースバイケースとしか言えませんね。
以下、余談
（余談１）
ご質問文だけで、ほぼ十分な情報となっています。不足があるとすれば、
サービスの規模や、実際の利用状況、そして実際に発行しているSQLなど、
あまりにも詳細な情報が必要になってきますので、
そこまでは公の場でのやりとりでは、あまり行わないですね。
（余談２）
公開サーバだと、セキュリティレベルの関係で、使えない手になりますが、
Webサービスが公に公開されているものではなく、社内用Webなどであれば、
echo shell_exec('ps v w -u postgres');
といった具合で長時間動き続けているpidを見つけるといった方法でも、
運用状況を見ることが出来ますので、より細かな対応が可能になります。
（余談３）
私のところは php5.3.1 PostgreSQL8.4.1 ですが
５でしか使えない pg_ 関数もあり、使い出すと結構便利だったりします。
8.4 だと高速で、見た目も判り易いSQLが書けます。
ただ、php5にアップすると余計なワーニングが出まくりとかで、
システム全体的に見直しが必要になってしまいますけど、
バージョンアップは勧めたいですね。
（当方では分析用に長いSQLを頻繁に書くのですが最高、半分の長さになり、
処理時間１２倍速というトンでもないものまで出ました。
元のSQLが効率悪かったとも言えるけど・・・。）
No.1
54140
24pt
まずはお願いなのですが、
どんなスクリプトを使ってPostgreSQLにアクセスしているのかなど
何も判らないと回答は難しくなりますので、必須だとご記憶ください。
ご質問の状況だけでは、PHPスクリプトを使ってPostgreSQLにアクセスしているのか、
別の方法でアクセスしているのかも分からないのです。
これは失礼いたしました。
PHPスクリプトを使ってPostgreSQLにアクセスしています。
httpd.confでは、extension=php_pgsql.soが有効になってます。
具体的な関数としてpg_connect関数を使用して同一セグメント内にいる別サーバーにインストールされたPostgreSQLにアクセスしています。
SQLの実行は、pg_exec関数を使っており、通常のSQLの動作(Select、update、insert＆delete)に
ついてはこれまで5年間問題なく動作しています。
(途中postgreSQLやphpのバージョンアップはしました。）
SQL呼び出し後は、pg_close関数で接続を閉じるようにしています。
恐縮ですが、他に必要な情報がありましたら教えて頂ければ追記します。
No.2
2915301
ここでベストアンサー
32pt
SELECT pg_cancel_backend(pid); でキル！
http://www.postgresql.jp/document/pg830doc/html/functions-admin....
あとは、どのようにして状態を得るか、また、どうのような状態なら、
消してしまうかという点ですが、参照系のシステムであるならば、
単純に pg_locksテーブル を見てpidを取得し、キルという流れで良いかもしれません。
このあたりの対応はシステムによりますので、ケースバイケースとしか言えませんね。
以下、余談
（余談１）
ご質問文だけで、ほぼ十分な情報となっています。不足があるとすれば、
サービスの規模や、実際の利用状況、そして実際に発行しているSQLなど、
あまりにも詳細な情報が必要になってきますので、
そこまでは公の場でのやりとりでは、あまり行わないですね。
（余談２）
公開サーバだと、セキュリティレベルの関係で、使えない手になりますが、
Webサービスが公に公開されているものではなく、社内用Webなどであれば、
echo shell_exec('ps v w -u postgres');
といった具合で長時間動き続けているpidを見つけるといった方法でも、
運用状況を見ることが出来ますので、より細かな対応が可能になります。
（余談３）
私のところは php5.3.1 PostgreSQL8.4.1 ですが
５でしか使えない pg_ 関数もあり、使い出すと結構便利だったりします。
8.4 だと高速で、見た目も判り易いSQLが書けます。
ただ、php5にアップすると余計なワーニングが出まくりとかで、
システム全体的に見直しが必要になってしまいますけど、
バージョンアップは勧めたいですね。
（当方では分析用に長いSQLを頻繁に書くのですが最高、半分の長さになり、
処理時間１２倍速というトンでもないものまで出ました。
元のSQLが効率悪かったとも言えるけど・・・。）
なるほど、ありがとうございます。
大変ためになります。
pg_lockって時間を持ってないのですね。
少し仕組みを検討します。
No.3
1624
24pt
>大量データのSQL(SELECT)を実行したときに、待ちきれないのでページを閉じると
>そのままPostgreSQLへのセッションがKillするまで永久に残ってしまいます。
残るのは通常動作です。
SQLの見直しか、DBの最適化をするか、仕様を見直すことをお勧めします。
トリッキーな方法を使うと必ず痛い目にあいますよ。
おっしゃる通りですね。
ＳＱＬ見直しやＤＢ最適化や仕様変更などができてりゃ
そもそもこんな質問しないかも。
って感じです。
トリッキーでダメだったら、今までどおりときどきサーバー見て
ゾンビプロセスをkill生活をします。
goobee
2010/02/01 18:41:26
2
1
1
2
178
174
pinkymonk
kn1967
なるほど、ありがとうございます。
大変ためになります。
pg_lockって時間を持ってないのですね。
少し仕組みを検討します。