gmirror performance

[Marcus Reid]

On Wed, Mar 16, 2011 at 02:48:35PM +0100, Lorenzo Perone wrote:
> On 16.03.11 13:00, Ivan Voras wrote:
> 
> >On 15/03/2011 15:56, Lorenzo Perone wrote:
> ...
> >>I'd expect read performance to be noticeably higher than write
> >>performance. Why is it not the case? Wrong expectation? :/
> 
> >Maybe. You can't expect that RAID-1 will have as good performance as
> >RAID-0 but you might achieve better performance for sequential reads
> >with long buffers. Try setting the vfs.read_max sysctl to 128 and see if
> >it helps you.
> 
> It *does* help!
> 
> Thanx a great lot! I knew I it was a PEBKAC :)
> 
> sysctl vfs.read_max=128
> configure -b load mirr0
> 
> just gave me 70MB/s more when reading (256640376 bytes/sec) :)
> 
> >(you might want to leave the gmirror algorithm to the
> >>default "load" and increase the stripe size to something sane, like 16k).
> 
> If You meant gmirror configure -s 16384 mirr0: this didn't change 
> anything for -b load, as expected, but it did change a little for -b split.
> 
> To sum up some results, fwimc:
> 
> test case:
> 
> umount /mnt && mount /dev/mirror/mirr0p4 /mnt && \
> dd if=/mnt/2gigfile.dat bs=1m of=/dev/null
> 
> * with default vfs.read_max=8
> 
> -b split -s 2048:
>   173875942 bytes/sec
> 
> -b load:
>   195143412 bytes/sec
> 
> * with vfs.read_max=128
> 
> -b split -s 2048:
>   191024137 bytes/sec
> 
> -b load:
>   258329216 bytes/sec

Wow, that's great.  I just almost doubled big sequential read performance
on one of my machines with this too.  The question now is why the defaults
are the way they are...  Does a big vfs.read_max (described as "Cluster
read-ahead max block count") pessimize performance in some other way?

Marcus