Gmirror performanc

Willem Jan Withagen wjw at digiware.nl
Wed Oct 25 20:35:04 UTC 2006


Oliver Fromme wrote:
> Guido van Rooij wrote:
>  > Anyway, I created a gm device and a partition. Now the read performance
>  > is not what I'd expect.
>  > I have the partition on two SATA devices on different controlers.
>  > I get around 60MB/s for each disk. I can get that speed from both disks
>  > simultaneously.
>  > Now when I dd from the gm device, I don't get any speed higher than that.
> 
> That's expected.
> 
>  > I tried with -b split -s <various sizes>, -b round-robin, -b load.
>  > (dd-ing as done with a bs of 1m; I see the transaction size is 128Kb,
>  > unless the split method is used, in which case the transaction size
>  > gies down. When round-robin is used, the transaction size is 128Kb/s,
>  > but the number of transaction per second goes down.).
>  > 
>  > I cannot explain why I should not get a higher read speed. Anyone?
> 
> dd is a sequential, single-threaded operation, so it will
> only use one disk at a time.  It's not really suitable as
> a benchmark for real-world things.
> 
> In the real world [TM] you have multiple processes that
> access the file system at random.  Here you will benefit
> from the mirror, because accesses will be distributed
> among the disks.

I'm still not really convinced that this should be the case....
That the real world can use the inherent parallelism is more than 
obvious. Unstructured diskaccess (aka seeks) counteract this in that 
same real world.

The dd process is able to read the data way much faster from the 
filesystem. So if there is/was any way of forking/multiplexing the data 
in the kernel buffers to both disks in parallel then you should see more 
than the speed of 1 disk.  This is of course also dependent on the 
amount of prefetching that is done.
Now on a raw disk I would not expect that to happen, other than the 
cache on the disk. On a filesystem I would expect the OS to take care of 
this possibility. And perhaps I would not expect an full doubling of the 
performance, since that is the theoretical max. But no gain at all is 
sort of disapointing.

But like you say, this is rather academic since this type of access is 
very synthetic.

--WjW


More information about the freebsd-stable mailing list