Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 473B91337BBA for ; Wed, 23 Mar 2011 10:13:40 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 49057-08 for ; Wed, 23 Mar 2011 13:13:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp2.peak6.com (smtp2.peak6.com [38.98.137.9]) by mail.postgresql.org (Postfix) with ESMTP id AECF61337B92 for ; Wed, 23 Mar 2011 10:13:29 -0300 (ADT) X-AuditID: 0a02cb1e-b7bf8ae00000096d-a4-4d89f1f841fe Message-ID: <4D89F1F8.1080609@peak6.com> Date: Wed, 23 Mar 2011 08:13:28 -0500 From: Shaun Thomas Reply-To: sthomas@peak6.com Organization: Peak6 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.7) Gecko/20100720 Lightning/1.0b2 Thunderbird/3.1.1 MIME-Version: 1.0 To: Scott Marlowe CC: felix , "pgsql-performance@postgresql.org" Subject: Re: good old VACUUM FULL References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed content-transfer-encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAZE= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201103/276 X-Sequence-Number: 42955 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@peak6.com ______________________________________________ See http://www.peak6.com/email_disclaimer.php for terms and conditions related to this email