Re: [Again] Postgres performance problem

From: ruben(at)rentalia(dot)com
To: "Decibel!" <decibel(at)decibel(dot)org>
Cc: db(at)zigo(dot)dhs(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: [Again] Postgres performance problem
Date: 2007-09-12 07:42:29
Message-ID: 46E79865.906@rentalia.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Decibel! escribió:
> On Tue, Sep 11, 2007 at 09:49:37AM +0200, Ruben Rubio wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> db(at)zigo(dot)dhs(dot)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.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message El-Lotso 2007-09-12 08:09:33 Re: Re: 500rows = 1min/2.5k rows=20min/6K rows 2 hours and still running
Previous Message Claus Guttesen 2007-09-12 07:17:23 Re: Hardware spec