Slony-Iの同期処理(PostgreSQL)でドン詰まった件

なんかねtop叩くと、PostgreSQLのユーザープロセスで、FETCH とかいうやつが、
メモリを50パーセントとか食って、でーんとしてやがるんですよ。
おかげで、他がおっせぇおっせぇ。
 
で、そのプロセス番号で、

select * from pg_stat_activity where procpid=プロセス番号

とかやって、SQLみてみると、

fetch 100 from LOG;

とかいう頭悪そうなヤツがいやがる。
 
ネットで検索したら↓で外人さんが、、
http://osdir.com/ml/db.postgresql.slony1.general/2006-10/msg00018.html
アイドルしてるプロセスをぶっ殺して、pg_listener と sl_log_1 に
VACUUM ANALYZEかけろや、と。
 
ただ、片っ端からアイドルしてるプロセスを切っちゃうのもなんか不安だったので・・・
ネットを徘徊してたら↓なんか出てきた。(バージョン古そうだけど、この際知るか・・・w)
http://old.postgresql.jp/wg/jpugdoc/slony/1.1.0/adminguide/faq.html#AEN3120
で、↓こいつで問い合わせなさい、と。

select * from pg_stat_activity where current_query like ‘%IDLE% in transaction’;

“待機中のトランザクション”を探し出し、年老いたトランザクションを保持している
プロセスを見つけることができるはずだ、と。#誰が訳したんすかね?センスあるよねぇ。
そいつが原因で、sl_log_1が肥大化したりバキュームがかからくなっちゃったりするんだと。
 
でもって、何週間も前から、デーンと居座っている、怪しいプロセスを発見して。。。

SELECT pg_cancel_backend(プロセスID);

オリャっとやってやったわけですよ。

そしたら、全然死なないでやんの。

仕方ないから、pg_stat_activity からクライアント(アクセス元)のIPとポートを特定して、

netstat -p | grep ポート番号

で、プログラムとプロセス番号を特定してやって。

あぁ、、、お前さんかぁ、、、、的な。。。
確かになぁ的な。。。。。今すぐ楽にしてやるぜぇって感じでkillしてやりました。

んでもって、バキュームしてやったー。

vacuum analyze pg_listener;
vacuum analyze ほげほげ.sl_log_1;

 
だいぶ性能上がってきたと思われ。
あー、今日はゆっくり寝れるといいのぅ。
 

PostgreSQL全機能バイブル
PostgreSQL全機能バイブル

posted with amazlet at 13.06.10
鈴木 啓修
技術評論社
売り上げランキング: 44,877

コメント

  1. […] 昔はSlony-1とか、Ludiaとか、泥臭い運用とか(バキュームとか、、)やってましたが、 最近はPostgreSQLからはめっきり遠ざかっていて、どうかなーと思っていましたが、参加できてよかったで […]

タイトルとURLをコピーしました