pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <gsmith@gregsmith.com>
To: Thomas Finneid <tfinneid@student.matnat.uio.no>
Cc: pgsql-performance@postgresql.org
Subject: Re: slow update of index during insert/copy
Date: Tue, 2 Sep 2008 03:57:27 -0400 (EDT)
Message-ID: <Pine.GSO.4.64.0809020340370.17733@westnet.com> (raw)
In-Reply-To: <48BCDF9C.5020906@ifi.uio.no>
References: <48BA9D65.2020001@ifi.uio.no>
	<48BB4A2D.9080404@postnewspapers.com.au>
	<48BBD22E.4090308@ifi.uio.no>
	<Pine.GSO.4.64.0809011558080.10428@westnet.com>
	<48BCDF9C.5020906@ifi.uio.no>

On Tue, 2 Sep 2008, Thomas Finneid wrote:

>> You should try setting this to open_sync , that can be considerably faster 
>> for some write-heavy situations.  Make sure to test that throughly though, 
>> there are occasional reports of issues with that setting under Linux
>
> The production machine is Solaris 10 running on a Sun v980. Do you know of it 
> has any issues like these?

On Solaris you can safely use open_datasync which is a bit better than 
open_sync.  For best results, you need to separate the xlog onto a 
separate partition and mount it using forcedirectio, because Postgres 
doesn't know how to use direct I/O directly on Solaris yet.

> Additionally, would I need to do any config changes when going from linux to 
> solaris?

Assuming the same amount of memory, the postgresql.conf should be 
basically the same, except for the wal_sync_method change mentioned above. 
If there's more RAM in the production server you can ramp up 
shared_buffers, effective_cache_size, and possibly work_mem 
proportionately.  The settings I suggested for maintenance_work_mem and 
wal_buffers are already near the useful upper limits for those parameters.

There are a few operating system level things you should consider tweaking 
on Solaris 10 for better PostgreSQL performance.  You need to be a bit 
more careful about the parameters used for the filesystem than on Linux, 
and the settings there vary considerably depending on whether you're using 
UFS or ZFS.  The best intro to that I know of is at 
http://blogs.sun.com/jkshah/entry/postgresql_east_2008_talk_best ; I added 
some clarification to a few points in there and some other Solaris notes 
at http://notemagnet.blogspot.com/2008_04_01_archive.html  Those should 
get you started.

I hope you're already looking into some sort of repeatable benchmarking 
that's representative of your application you can run.  You'll go crazy 
playing with all these settings without something like that.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



view thread (22+ messages)  latest in thread

Message-ID: <Pine.GSO.4.64.0809020340370.17733@westnet.com>
Permalink:  ../Pine.GSO.4.64.0809020340370.17733@westnet.com/
Also on:    postgresql.org/message-id/Pine.GSO.4.64.0809020340370.17733@westnet.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: gsmith@gregsmith.com, tfinneid@student.matnat.uio.no
  Subject: Re: slow update of index during insert/copy
  In-Reply-To: <Pine.GSO.4.64.0809020340370.17733@westnet.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox