From: | Shaun Thomas <sthomas(at)peak6(dot)com> |
---|---|
To: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
Cc: | felix <crucialfelix(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: good old VACUUM FULL |
Date: | 2011-03-23 13:13:28 |
Message-ID: | 4D89F1F8.1080609@peak6.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 03/23/2011 01:16 AM, Scott Marlowe wrote:
> Then either cluster failed (did you get an error message) or the table
> was not bloated. Given that it looks like it was greatly reduced in
> size by the vacuum full, I'd guess cluster failed for some reason.
Or it just bloated again. Remember, he still hasn't changed his
max_fsm_pages setting, and that table apparently experiences *very* high
turnover.
A 25x bloat factor isn't unheard of for such a table. We have one that
needs to have autovacuum or be manually vacuumed frequently because it
experiences several thousand update/deletes per minute. The daily
turnover of that particular table is around 110x. If our fsm settings
were too low, or we didn't vacuum regularly, I could easily see that
table quickly becoming unmanageable. I fear for his django_session table
for similar reasons.
Felix, I know you don't want to "experiment" with kernel parameters, but
you *need* to increase your max_fsm_pages setting.
--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas(at)peak6(dot)com
______________________________________________
See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email
From | Date | Subject | |
---|---|---|---|
Next Message | Jochen Erwied | 2011-03-23 13:19:59 | Re: buffercache/bgwriter |
Previous Message | Uwe Bartels | 2011-03-23 12:51:31 | buffercache/bgwriter |