On Wed, 7 Nov 2012, Stefan Priebe wrote:
> Hello list,
>
> i've done some benchmarks regarding striping / v1 / v2.
>
> Results:
> format 1:
>
> write: io=5739MB, bw=65278KB/s, iops=16319, runt= 90029msec
> read : io=5771MB, bw=65636KB/s, iops=16408, runt= 90030msec
> write: io=77224MB, bw=874044KB/s, iops=213, runt= 90473msec
> read : io=178840MB, bw=1983MB/s, iops=495, runt= 90168msec
>
> format 2:
>
> --stripe-count 8 --stripe-unit 524288 -s 4194304
>
> write: io=5377MB, bw=61147KB/s, iops=15286, runt= 90041msec
> read : io=5332MB, bw=60617KB/s, iops=15154, runt= 90067msec
> write: io=75136MB, bw=849285KB/s, iops=207, runt= 90593msec
> read : io=160292MB, bw=1777MB/s, iops=444, runt= 90226msec
>
> --stripe-count 4 --stripe-unit 1048576 -s 4194304
>
> write: io=5301MB, bw=60281KB/s, iops=15070, runt= 90046msec
> read : io=5367MB, bw=61031KB/s, iops=15257, runt= 90057msec
> write: io=74448MB, bw=840293KB/s, iops=205, runt= 90724msec
> read : io=170616MB, bw=1891MB/s, iops=472, runt= 90227msec
>
> So it seems right now that striping doesn't improve performance.
It's mainly going to help when you have a deep queue of small sequential
IOs, and the fact that they are all piling up on a single rbd block is
turning into a bottleneck. The rest of the time the overhead of splitting
things into smaller pieces will slow you down.
The intended use case is a database journal or something similar, where
the latency requirements prevent us from making larger IOs, but things are
still sequential.
rbd bench-write ...
will generate this workload.
sage
>
> Greets,
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
