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 F1C22529B2 for ; Mon, 18 Jul 2005 14:50:12 -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 12107-09 for ; Mon, 18 Jul 2005 17:50:04 +0000 (GMT) Received: from prospect.stortek.com (prospect.stortek.com [129.80.22.147]) by svr1.postgresql.org (Postfix) with ESMTP id ADE1252896 for ; Mon, 18 Jul 2005 14:50:02 -0300 (ADT) Received: from prospect.stortek.com (localhost [127.0.0.1]) by prospect.stortek.com (8.12.10/8.12.0) with ESMTP id j6IHo1Wl013926 for ; Mon, 18 Jul 2005 11:50:02 -0600 (MDT) Received: from unix.stortek.com (burma.stortek.com [129.80.16.110]) by prospect.stortek.com (8.12.10/8.12.0) with ESMTP id j6IHo1bc013921; Mon, 18 Jul 2005 11:50:01 -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 j6IHo0vn027391; Mon, 18 Jul 2005 11:50:00 -0600 (MDT) Date: Mon, 18 Jul 2005 11:49:52 -0600 From: Robert Creager To: tgl@sss.pgh.pa.us, matthew@zeut.net, pgsql-performance@postgresql.org Cc: Andy Hewitt III Subject: Re: Huge performance problem between 7.4.1 and 8.0.3 - CS issue? Message-ID: <20050718114952.00004ac5@C118181.stortek.com> 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/262 X-Sequence-Number: 13503 In regards to http://archives.postgresql.org/pgsql-performance/2005-07/msg00261.php Tom Says: > ... as indeed it does according to Robert's recent reports. Still > awaiting the definitive test, but I'm starting to think this is another > case of the strange behavior Ian Westmacott exhibited. Ok. This morning at around 7:30am I started tests against a freshly VACUUM FULL ANALYZE 803 database with the vacuum delay on and cron running vacuum analyze every 5 minutes. Around 8:15 I was starting to receive hits of a few seconds of high CS hits, higher than the previous 7 hour run on 741. I changed the vacuum delay to 0 and HUP'ed the server (how can I see the value vacuum_cost_delay run time?). By 10:30, I had vacuum jobs backed up since 9:20 and the queries were over 75 seconds. I'm currently running on 741 as I need to get work done today ;-) I'll restart the 803 db, vacuum full analyze again and next opportunity (maybe tonight), start runs again with cron vacuum and a vacuum_cost_delay of 0, unless I should try something else? Cheers, Rob -- Robert Creager Advisory Software Engineer Phone 303.673.2365 Pager 888.912.4458 Fax 303.661.5379 StorageTek