X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 3EB6F11F66CE for ; Wed, 5 Apr 2006 18:31:32 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 98543-03 for ; Wed, 5 Apr 2006 18:31:31 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from my.endian.it (unknown [62.146.87.34]) by postgresql.org (Postfix) with ESMTP id 16BF411F66E5 for ; Wed, 5 Apr 2006 18:31:28 -0300 (ADT) Received: from dell.home.lan (host14-128.pool8251.interbusiness.it [82.51.128.14]) (authenticated (0 bits)) by my.endian.it (8.11.6/8.11.6) with ESMTP id k35MYFr16778; Thu, 6 Apr 2006 00:34:15 +0200 Subject: Re: bad performance on Solaris 10 From: Chris Mair To: pgsql-performance@postgresql.org Cc: markir@paradise.net.nz, josh@agliodbs.com, llonergan@greenplum.com In-Reply-To: <1144111178.3723.80.camel@dell.home.lan> References: <1144111178.3723.80.camel@dell.home.lan> Content-Type: text/plain Date: Wed, 05 Apr 2006 23:31:25 +0200 Message-Id: <1144272685.4562.43.camel@dell.home.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-22) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200604/64 X-Sequence-Number: 18148 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