Luke,
ISTM that the main performance issue for xlog is going to be the rate at
which fdatasync operations complete, and the stripe size shouldn't hurt
that.
I thought so. However, I've also tried running the PGDATA off of the RAID1 as a test and it is poor.
What are your postgresql.conf settings for the xlog: how many logfiles,
sync_method, etc?
wal_sync_method = fsync # the default varies across platforms:
# fsync, fdatasync, open_sync, or open_datasync
# - Checkpoints -
checkpoint_segments = 14 # in logfile segments, min 1, 16MB each
checkpoint_timeout = 300 # range 30-3600, in seconds
#checkpoint_warning = 30 # 0 is off, in seconds
#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5
What stumps me is I use the same settings on a Sun box (dual Opteron 4GB w/ LSI MegaRAID 128M) with the same data. This is on pg 7.4.13.
> The 6-disc RAID10 you speak of is on the SmartArray 642 RAID adapter.
Interesting - the seek rate is very good for two drives, are they 15K RPM?
Nope. 10K. RPM.
HP's recommendation for testing is to connect the RAID1 to the second channel off of the SmartArray 642 adapter since they use the same driver, and, according to HP, I should not have to rebuilt the RAID1.
I have to send the new server to the hospital next week, so I have very little testing time left.
Steve