OK... Is all this 3x; 6x potential performance boost still going to hold
true in a Single Controller scenario?
Hardware is x4100's (Solaris 10) w/ 6-disk raidz on external 3320's?
I seem to remember /(wait... checking Notes...) / correct... the ZFS
filesystem is < 50% capacity.
This info could lead me to follow why I was also seeing 'sched' running
a lot as well...
---michael
===================================================================
)_____________________________________________________________________________(
Matthew Ahrens wrote:
Bart Smaalders wrote:
Ian Collins wrote:
Bart Smaalders wrote:
A 6 disk raidz set is not optimal for random reads, since each disk in
the raidz set needs to be accessed to retrieve each item. Note
that if
the reads are single threaded, this doesn't apply. However, if
multiple
reads are extant at the same time, configuring the disks as 2 sets of
3 disk raidz vdevs or 3 pairs of mirrored disk will result in 2x
and 3x
(approx) total parallel random read throughput.
Actually, with 6 disks as 3 mirrored pairs, you should get around 6x
the random read iops of a 6-disk raidz[2], because each side of the
mirror can fulfill different read requests. We use the checksum to
verify correctness, so we don't need to read the same data from both
sides of the mirror.
I'm not sure why, but when I was testing various configurations with
bonnie++, 3 pairs of mirrors did give about 3x the random read
performance of a 6 disk raidz, but with 4 pairs, the random read
performance dropped by 50%:
interesting.... I wonder if the blocks being read were stripped across
two mirror pairs; this would result in having to read 2 sets
of mirror pairs, which would produce the reported results...
Each block is entirely[*] on one top-level vdev (ie, mirrored pair in
this case), so that would not happen. The observed performance
degradation remains a mystery.
--matt
[*] assuming you have enough contiguous free space. On nearly-full
pools, performance can suffer due to (among other things) "gang
blocks" which essentially break large blocks into many several smaller
blocks if there isn't enough contiguous free space for the large block.
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
