Re: Performance considerations for very heavy INSERT traffic - Mailing list pgsql-performance

From Vivek Khera
Subject Re: Performance considerations for very heavy INSERT traffic
Date
Msg-id 241EAFA1-B76D-46C1-9536-69B3B05AA64C@khera.org
Whole thread Raw
In response to Re: Performance considerations for very heavy INSERT traffic  (Brandon Black <blblack@gmail.com>)
List pgsql-performance

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.

+1-301-869-4449 x806



pgsql-performance by date:

Previous
From: Vivek Khera
Date:
Subject: Re: Performance considerations for very heavy INSERT traffic
Next
From: "Gurpreet Aulakh"
Date:
Subject: Query slower on 8.0.3 (Windows) vs 7.3 (cygwin)