Skip site navigation (1) Skip section navigation (2)

Re: Performance problems testing with Spamassassin

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Cc: "Luke Lonergan" <LLonergan(at)greenplum(dot)com>,"Andrew McMillan" <andrew(at)catalyst(dot)net(dot)nz>,"Matthew Schumacher" <matt(dot)s(at)aptalaska(dot)net>
Subject: Re: Performance problems testing with Spamassassin
Date: 2005-07-29 16:47:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance

> 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 

Josh Berkus
Aglio Database Solutions
San Francisco

In response to


pgsql-performance by date

Next:From: Matteo BeccatiDate: 2005-07-29 16:50:44
Subject: ltree <@ operator selectivity causes very slow plan
Previous:From: Dirk Lutzeb├ĄckDate: 2005-07-29 16:45:12
Subject: Performance problems on 4/8way Opteron (dualcore) HP DL585

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group