Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id CC68D9F9A1E for ; Wed, 12 Sep 2007 04:43:10 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 39100-10 for ; Wed, 12 Sep 2007 04:43:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mail.rentalia.com (mail.rentalia.com [213.192.209.8]) by postgresql.org (Postfix) with ESMTP id 4D4BE9F99E6 for ; Wed, 12 Sep 2007 04:43:04 -0300 (ADT) Received: (qmail 15669 invoked by uid 509); 12 Sep 2007 09:43:01 +0200 Received: from 212.145.220.117 by nemo (envelope-from , uid 507) with qmail-scanner-1.25-st-qms (clamdscan: 0.88.7/2476. spamassassin: 3.0.6. perlscan: 1.25-st-qms. Clear:RC:0(212.145.220.117):SA:0(-2.6/5.0):. Processed in 0.308565 secs); 12 Sep 2007 07:43:01 -0000 X-Antivirus-MYDOMAIN-Mail-From: ruben@rentalia.com via nemo X-Antivirus-MYDOMAIN: 1.25-st-qms (Clear:RC:0(212.145.220.117):SA:0(-2.6/5.0):. Processed in 0.308565 secs Process 15649) Received: from pooladsl-a-29-117.ipcom.comunitel.net (HELO ?192.168.2.48?) (ruben@rentalia.com@212.145.220.117) by mail.rentalia.com with SMTP; 12 Sep 2007 09:43:00 +0200 Message-ID: <46E79865.906@rentalia.com> Date: Wed, 12 Sep 2007 09:42:29 +0200 From: ruben@rentalia.com User-Agent: Thunderbird 1.5.0.13 (X11/20070824) MIME-Version: 1.0 To: "Decibel!" CC: db@zigo.dhs.org, pgsql-performance@postgresql.org Subject: Re: [Again] Postgres performance problem References: <46E636CB.8080008@rentalia.com> <43393.192.121.104.48.1189495883.squirrel@zigo.dhs.org> <46E64891.9080005@rentalia.com> <20070911225242.GG38801@decibel.org> In-Reply-To: <20070911225242.GG38801@decibel.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/221 X-Sequence-Number: 26766 Decibel! escribió: > On Tue, Sep 11, 2007 at 09:49:37AM +0200, Ruben Rubio wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> db@zigo.dhs.org escribi?: >>>> Last time I had this problem i solved it stopping website, restarting >>>> database, vacuumm it, run again website. But I guess this is going to >>>> happen again. >>>> >>>> I would like to detect and solve the problem. Any ideas to detect it? >>> Do you have very long transactions? Maybe some client that is connected >>> all the time that is idle in transaction? >> There should not be long transactions. I ll keep an eye on Idle transactions >> >> I m detecting it using: >> >> echo 'SELECT current_query FROM pg_stat_activity;' | >> /usr/local/pgsql/bin/psql vacadb | grep IDLE | wc -l > > If you're using VACUUM FULL, you're doing something wrong. :) I do a VACUUM FULL VERBOSE ANALYZE each day. I save all logs so I can check if vacuum is done properly.(it is) Run lazy > vacuum frequently enough (better yet, autovacuum, but cut all of 8.1's > autovac parameters in half), and make sure your FSM is big enough I checked that there is no warnings about FSM in logs. (also in logs from vacuum). Is it reliable? What do u mean for "cut all of 8.1's autovac parameters in half" Maybe default autovac parameters? > (periodic vacuumdb -av | tail is an easy way to check that). I ll keep an eye on it. > > Try a REINDEX. VACUUM FULL is especially hard on the indexes, and it's > easy for them to seriously bloat. Reindex is done everyday after VACUUM FULL VERBOSE ANALYZE. I save also the output averyday and save it into a log, and I can check that it is done properly.