Hi,
The problem : Postgres is becoming slow, day after day, and only a full vacuum
fixes the problem.
Information you may need to evaluate :
The problem lies on all tables and queries, as far as I can tell, but we can
focus on a single table for better comprehension.
The queries I am running
Sorry, forgot to mention the most obvious and important information :
My postgres is 8.4.2
On Sep 24, 2012, at 13:33, Kiriakos Tsourapas wrote:
> Hi,
>
> The problem : Postgres is becoming slow, day after day, and only a full
> vacuum fixes the problem.
>
> Informati
Hi,
Thank you for your response.
Please find below my answers/comments.
On Sep 24, 2012, at 15:21, Julien Cigar wrote:
> Hello,
>
> 1) upgrade your PostgreSQL installation, there have been numerous bugfixes
> releases since 8.4.2
Not possible right now. It will have to be the last solution.
>
Thank you,
I will take this into consideration, since upgrading to 9 will be much harder I
assume...
On Sep 24, 2012, at 15:23, MirrorX wrote:
> i remember having a server with 8.4.4 where we had multiple problems with
> autovacuum.
> if i am not mistaken there are some bugs related with vacuu
Hi Mark,
When the problem appears, vacuuming is not helping. I ran vacuum manually and
the problem was still there. Only full vacuum worked.
As far as I have understood, autovacuuming is NOT doing FULL vacuum. So,
messing around with its values should not help me in any way.
Thanks
>
> Giv
Hi,
Suggestion noted.
Nevertheless, I cannot imagine what it would help. Actually, the cost_delay
makes autovacuum freeze when it takes more time than expected, therefore,
having it enabled should help the system.
I may try it as a last possible resolution (remember that I have to wait for a
c
Dear all,
I am taking your suggestions one step at a time.
I changed my configuration to a much more aggressive autovacuum policy (0.5%
for analyzing and 1% for autovacuum).
autovacuum_naptime = 1min
autovacuum_vacuum_threshold = 50
#autovacuum_analyze_threshold = 50
autovacuum_vacuum_scale_fac
Hi Kevin,
On Sep 26, 2012, at 14:39, Kevin Grittner wrote:
>
> I am concerned that your initial email said that you had this
> setting:
>
> autovacuum_naptime = 28800
>
> This is much too high for most purposes; small, frequently-modified
> tables won't be kept in good shape with this setting.
Dear all,
Just letting you know that making the autovacuum policy more aggressive seems
to have fixed the problem.
It's been 4 days now and everything is running smoothly.
Just a reminder, what I changed was :
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
making a
I am posting back to let you know that the DB is working fine since the changes
in the autovacuum settings.
I am including the changes I made for later reference to anyone that may face
similar issues.
Thank you all for your time and help !
On Sep 28, 2012, at 9:52, Kiriakos Tsourapas wrote
10 matches
Mail list logo
