On 8/24/06, Jeff Davis <pgsql@xxxxxxxxxxx> wrote:
On Thu, 2006-08-24 at 09:21 -0400, Merlin Moncure wrote: > On 8/22/06, Jeff Davis <pgsql@xxxxxxxxxxx> wrote: > > On Tue, 2006-08-22 at 17:56 -0400, Bucky Jordan wrote: > it's not the parity, it's the seeking. Raid 5 gives you great > sequential i/o but random is often not much better than a single > drive. Actually it's the '1' in raid 10 that plays the biggest role > in optimizing seeks on an ideal raid controller. Calculating parity > was boring 20 years ago as it inolves one of the fastest operations in > computing, namely xor. :) Here's the explanation I got: If you do a write on RAID 5 to something that is not in the RAID controllers cache, it needs to do a read first in order to properly recalculate the parity for the write.
it's worse than that. if you need to read something that is not in the o/s cache, all the disks except for one need to be sent to a physical location in order to get the data. Thats the basic rule with striping: it optimizes for sequential i/o in expense of random i/o. There are some optimizations that can help, but not much. caching by the controller can increase performance on writes because it can optimize the movement across the disks by instituting a delay between the write request and the actual write. raid 1 (or 1+x) is the opposite. It allows the drive heads to move independantly on reads when combined with some smart algorithms. writes however must involve all the disk heads however. Many controllers do not to seem to optimze raid 1 properly although linux software raid seems to. A 4 disk raid 1, for example, could deliver four times the seek performance which would make it feel much faster than a 4 disk raid 0 under certain conditions.
> with 6 relatively small disks I think single raid 10 volume is the > best bet. however above 6 dedicated wal is usually worth considering. > since wal storage requirements are so small, it's becoming affordable > to look at solid state for the wal. I've often wondered about that. To a certain degree, that's the same effect as just having a bigger battery-backed cache, right?
yeah, if the cache was big enough to cover the volume. the wal is also fairly sequenctial i/o though so I'm not sure this would help all that much after thinking about it. would be an interesting test though. merlin
