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: | 200507290947.03700.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Matteo Beccati | 2005-07-29 16:50:44 | ltree <@ operator selectivity causes very slow plan |
Previous Message | Dirk Lutzebäck | 2005-07-29 16:45:12 | Performance problems on 4/8way Opteron (dualcore) HP DL585 |