From: | Vivek Khera <vivek(at)khera(dot)org> |
---|---|
To: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Performance considerations for very heavy INSERT traffic |
Date: | 2005-09-21 15:57:42 |
Message-ID: | 241EAFA1-B76D-46C1-9536-69B3B05AA64C@khera.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2005-09-21 16:01:48 | Re: Performance considerations for very heavy INSERT traffic |
Previous Message | Vivek Khera | 2005-09-21 15:35:02 | Re: CHECK vs REFERENCES |