David Lang wrote:
> the application can' tell the difference, but the reason for seperating
> them isn't for the application, it's so that different pieces of
> hardware can work on different things without having to bounce back and
> forth between them.
>
> useing the same drives with LVM doesn't achieve this goal.
>
> the problem is that the WAL is doing a LOT of writes, and postgres waits
> until each write is completed before going on to the next thing (for
> safety), if a disk is dedicated to the WAL then the head doesn't move
> much. if the disk is used for other things as well then the heads have
> to move across the disk surface between the WAL and where the data is.
> this drasticly slows down the number of items that can go into the WAL,
> and therefor slows down the entire system.
>
> this slowdown isn't even something as simple as cutting your speed in
> half (half the time spent working on the WAL, half spent on the data
> itself), it's more like 10% spent on the WAL, 10% spent on the data, and
> 80% moveing back and forth between them (I am probably wrong on the
> exact numbers, but it is something similarly drastic)
Yeah, I don't think I was clear about the config. It's (4) disks setup
as a pair of RAID1 sets. My original config was pgsql on the first RAID
set (data and WAL). I'm now experimenting with putting the data/pg_xlog
folder on the 2nd set of disks.
Under the old setup (everything on the original RAID1 set, in a
dedicated 32GB LVM volume), I was seeing 80-90% wait percentages in
"top". My understanding is that this is an indicator of an overloaded /
bottlenecked disk system. This was while doing massive inserts into a
test table (millions of narrow rows). I'm waiting to see what happens
once I have data/pg_xlog on the 2nd disk set.
Thanks for the input.