X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id BD93F52932 for ; Tue, 19 Jul 2005 15:10:02 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 42519-03 for ; Tue, 19 Jul 2005 18:09:53 +0000 (GMT) Received: from sherman.stortek.com (sherman.stortek.com [129.80.22.146]) by svr1.postgresql.org (Postfix) with ESMTP id 7E5645284F for ; Tue, 19 Jul 2005 15:09:52 -0300 (ADT) Received: from sherman.stortek.com (localhost [127.0.0.1]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j6JI9rD4000814 for ; Tue, 19 Jul 2005 12:09:53 -0600 (MDT) Received: from unix.stortek.com (burma.stortek.com [129.80.16.110]) by sherman.stortek.com (8.12.10/8.12.0) with ESMTP id j6JI9qDC000810; Tue, 19 Jul 2005 12:09:53 -0600 (MDT) Received: from C118181.stortek.com (c118181.stortek.com [129.80.81.172]) by unix.stortek.com (8.12.10/8.12.0) with ESMTP id j6JI9pvn028181; Tue, 19 Jul 2005 12:09:52 -0600 (MDT) Date: Tue, 19 Jul 2005 12:09:51 -0600 From: Robert Creager To: Tom Lane Cc: Robert Creager , pgsql-performance@postgresql.org, Andy Hewitt III Subject: Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Message-ID: <20050719120951.00002520@C118181.stortek.com> In-Reply-To: <7322.1121792062@sss.pgh.pa.us> References: <20050718114952.00004ac5@C118181.stortek.com> <15472.1121709173@sss.pgh.pa.us> <20050719105014.00007635@C118181.stortek.com> <7322.1121792062@sss.pgh.pa.us> Organization: StorageTek X-Mailer: Sylpheed-Claws 1.0.4.1 Win32 (GTK+ 1.3.0; Win32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200507/298 X-Sequence-Number: 13539 On Tue, 19 Jul 2005 12:54:22 -0400 Tom Lane wrote: > Hmm, I hadn't thought about the possible impact of multiple concurrent > vacuums. Is the problem caused by that, or has performance already gone > into the tank by the time the cron-driven vacuums are taking long enough > to overlap? Don't know just yet. When I run the vacuums manually on a healthy system on 741, they take less than 30 seconds. I've stopped the cron vacuum and canceled all the outstanding vacuum processes, but the 803 is still struggling (1/2 hour later). I'll re-start the database, vacuum full analyze and restart the runs without the cron vacuum running. Cheers, Rob