shinodogg.com

なんかね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;

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