On Sep 12, 2005, at 6:02 PM, Brandon Black wrote:
> - splitting the xlog and the data on distinct physical
> drives or arrays
> That would almost definitely help, I haven't tried it yet.
> Speaking of the xlog, anyone know anything specific about the WAL
> tuning parameters for heavy concurrent write traffic? What little
> I could dig up on WAL tuning was contradictory, and testing some
> random changes to the parameters hasn't been very conclusive yet.
> I would imagine the WAL buffers stuff could potentially have a
> large effect for us.
you will want to make your pg_xlog RAID volume BIG, and then tell
postgres to use that space: bump up checkpoint_segments (and suitably
the checkpoint timeouts). I run with 256 segments and a timeout of 5
minutes. The timeout refletcs your expected crash recovery time, so
adjust it wisely....
Also, you should consider how you split your drives across your RAID
data channels on your test machine: I put each pair of the RAID10
mirrors on opposite channels, so both channels of my RAID controller
are pretty evenly loaded during write.
Vivek Khera, Ph.D.
In response to
pgsql-performance by date
|Next:||From: Vivek Khera||Date: 2005-09-21 16:01:48|
|Subject: Re: Performance considerations for very heavy INSERT traffic|
|Previous:||From: Vivek Khera||Date: 2005-09-21 15:35:02|
|Subject: Re: CHECK vs REFERENCES|