Re: bad performance on Solaris 10 - Mailing list pgsql-performance

From Chris Mair
Subject Re: bad performance on Solaris 10
Date
Msg-id 1144272685.4562.43.camel@dell.home.lan
Whole thread Raw
In response to bad performance on Solaris 10  (Chris Mair <list@1006.org>)
Responses Re: bad performance on Solaris 10  ("Luke Lonergan" <llonergan@greenplum.com>)
Re: bad performance on Solaris 10  (Mark Kirkwood <markir@paradise.net.nz>)
Re: bad performance on Solaris 10  (Chris Mair <list@1006.org>)
Re: bad performance on Solaris 10  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
Hi,

thanks for all replys.

I've done a few tests.

Remounting the fs where $PGDATA lives with "forcedirectio"
(together with logging, that is default) did not help
(if not harm...) performance.

Doing what http://blogs.sun.com/roller/page/jkshah suggests:
  wal_sync_method = fsync (unchanged)
  wal_buffers = 128 (was 8)
  checkpoint_segments = 128 (was 3)
  bgwriter_all_percent = 0 (was 0.333)
  bgwriter_all_maxpages = 0 (was 5)
and leaving everything else default (solarispackages from pgfoundry)
increased performance ~ 7 times!

Playing around with these modifications I find that it's
actually just the
  wal_buffers = 128
alone which makes all the difference!

Quickly playing around with wal_buffers on Linux and Mac OS X
I see it influences the performance of my test a bit, maybe in the
10-20% range (I'm really doing quick tests, nothing systematic),
but nowhere near as spectacularly as on Solaris.

I'm happy so far, but I find it very surprising that this single
parameter has such an impact (only on) Solaris 10.

(my test program is a bulk inserts using PQputCopyData in large
transactions - all test were 8.1.3).

Bye, Chris





pgsql-performance by date:

Previous
From: "Juan Casero \(FL FLC\)"
Date:
Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3
Next
From: "Luke Lonergan"
Date:
Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3