X-Original-To: pgsql-performance-postgresql.org@postgresql.org
Received: from localhost (mx1.hub.org [200.46.208.251])
	by postgresql.org (Postfix) with ESMTP id DFBC59FA634
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 23 Jun 2006 08:56:18 -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 97418-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 23 Jun 2006 08:56:12 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-
Received: from mail.logix-tt.com (mail.logix-tt.com [212.211.145.186])
	by postgresql.org (Postfix) with ESMTP id 0A91B9FA5DD
	for <pgsql-performance@postgresql.org>;
	Fri, 23 Jun 2006 08:56:12 -0300 (ADT)
Received: from kingfisher.intern.logix-tt.com (Tb02f.t.pppool.de
	[89.55.176.47])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.logix-tt.com (Postfix) with ESMTP id 184A865876;
	Fri, 23 Jun 2006 13:57:41 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by kingfisher.intern.logix-tt.com (Postfix) with ESMTP id 712611852EF72;
	Fri, 23 Jun 2006 13:56:16 +0200 (CEST)
Message-ID: <449BD6E0.10305@logix-tt.com>
Date: Fri, 23 Jun 2006 13:56:16 +0200
From: Markus Schaber <schabi@logix-tt.com>
Organization: Logical Tracking and Tracing International AG, Switzerland
User-Agent: Thunderbird 1.5.0.2 (X11/20060516)
MIME-Version: 1.0
To: Tim Allen <tim@proximity.com.au>
Cc: pgsql-performance@postgresql.org
Subject: Re: SAN performance mystery
References: <4491D61B.9040507@proximity.com.au>
In-Reply-To: <4491D61B.9040507@proximity.com.au>
X-Enigmail-Version: 0.94.0.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200606/460
X-Sequence-Number: 19817

Hi, Tim,

Tim Allen wrote:
> One thing that has been
> apparent is that autovacuum has not been able to keep the database
> sufficiently tamed. A pg_dump/pg_restore cycle reduced the total
> database size from 81G to 36G.

Two first shots:

- Increase your free_space_map settings, until (auto)vacuum does not
warn about a too small FSM setting any more

- Tune autovacuum to run more often, possibly with a higher delay
setting to lower the load.

If you still have the original database around,

> Performing the restore took about 23 hours.

Try to put the WAL on another spindle, and increase the WAL size /
checkpoint segments.

When most of the restore time was spent in index creation, increase the
sort mem / maintainance work mem settings.


HTH,
Markus

-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org