From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: pgsql-performance@postgresql.org
Subject: Re: Performance problems testing with Spamassassin
Date: Fri, 29 Jul 2005 09:47:03 -0700
User-Agent: KMail/1.8
Cc: "Luke Lonergan" <LLonergan@greenplum.com>,
	"Andrew McMillan" <andrew@catalyst.net.nz>,
	"Matthew Schumacher" <matt.s@aptalaska.net>
References: <3E37B936B592014B978C4415F90D662D0C4221@MI8NYCMAIL06.Mi8.com>
In-Reply-To: <3E37B936B592014B978C4415F90D662D0C4221@MI8NYCMAIL06.Mi8.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200507290947.03700.josh@agliodbs.com>

Luke,

> work_mem = 131072               # min 64, size in KB

Incidentally, this is much too high for an OLTP application, although I don't 
think this would have affected the test.

> shared_buffers = 16000          # min 16, at least max_connections*2, 8KB
> each checkpoint_segments = 128       # in logfile segments, min 1, 16MB
> each effective_cache_size = 750000   # typically 8KB each
> fsync=false                     # turns forced synchronization on or off

Try changing:
wal_buffers = 256

and try Bruce's stop full_page_writes patch.

> I guess we see the real culprit here.  Anyone surprised it's the WAL?

Nope.  On high-end OLTP stuff, it's crucial that the WAL have its own 
dedicated disk resource.

Also, running a complex stored procedure for each and every word in each 
e-mail is rather deadly ... with the e-mail traffic our server at Globix 
receives, for example, that would amount to running it about 1,000 times a 
minute.   It would be far better to batch this, somehow, maybe using temp 
tables.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco