Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 2A0299FB3F8; Sun, 15 Oct 2006 11:52:22 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 45406-01; Sun, 15 Oct 2006 11:52:17 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from lynet.oppetid.no (oppetid.no [80.65.51.2]) by postgresql.org (Postfix) with ESMTP id 6AFA49FA5B4; Sun, 15 Oct 2006 11:52:17 -0300 (ADT) Received: by lynet.oppetid.no (Postfix, from userid 1019) id D091C11AF0A; Sun, 15 Oct 2006 16:52:12 +0200 (CEST) Date: Sun, 15 Oct 2006 16:52:12 +0200 From: Tobias Brox To: "Matthew T. O'Connor" Cc: Tobias Brox , Csaba Nagy , Edoardo Ceccarelli , postgres performance list , pgsql-admin@postgresql.org Subject: Re: [PERFORM] autovacuum on a -mostly- r/o table Message-ID: <20061015145212.GA13175@oppetid.no> References: <20061015095259.GA24002@oppetid.no> <453248DA.7050806@zeut.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453248DA.7050806@zeut.net> Organization: Group Nordicbet User-Agent: Mutt/1.5.9i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.176 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200610/99 X-Sequence-Number: 23402 [Matthew T. O'Connor - Sun at 10:42:34AM -0400] > Yeah, I think if the delay settings are too high it can cause problems, > that's part of the reason we have yet to turn these on be default since > we won't have enough data to suggest good values. Can you tell us what > settings you finally settled on? I'm still not yet settled, and the project manager is critical to autovacuum (adds complexity, no obvious benefits from it, we see from the CPU graphs that it's causing iowait, iowait is bad). We're going to run autovacuum biweekly now to see what effect it has on the server load. I've been using the cost/delay-setting of 200/200 for a week now, and I'm going to continue with 100/150 for a while. Are there any known disadvantages of lowering both values to the extreme - say, 20/20 instead of 200/200? That would efficiently mean "sleep as often as possible, and sleep for 1 ms for each cost unit spent" if I've understood the system right. Are there any logs that can help me, and eventually, are there any ready-made scripts for checking when autovacuum is running, and eventually for how long it keeps its transactions? I'll probably write up something myself if not.