Re: bad performance on Solaris 10

Поиск
Список
Период
Сортировка
От Chris Mair
Тема Re: bad performance on Solaris 10
Дата
Msg-id 1144272685.4562.43.camel@dell.home.lan
обсуждение исходный текст
Ответ на bad performance on Solaris 10  (Chris Mair <list@1006.org>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: "Juan Casero \(FL FLC\)"
Дата:
Сообщение: Re: Sun Fire T2000 and PostgreSQL 8.1.3
Следующее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Sun Fire T2000 and PostgreSQL 8.1.3