[DRBD-user] DRBD Performance

Lars Ellenberg lars.ellenberg at linbit.com
Fri Mar 7 18:42:08 CET 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On Fri, Mar 07, 2008 at 11:39:49AM -0000, Azeez Ahamed wrote:
> >
> >    It has been observed that when protocol A and B is used, there is
> >some impact on the I/O performance (especially on sequential writes)
> >compared to protocol C. But theoretically, protocols A and B should be faster than C. Why Tiobench results (http://www.drbd.org/performance .html) says that protocol C is good ?
> >
> >    Even i carried out performance tests (using Tiobench tool) on 8.0.3 build and i observed that the results are almost same as the one mentioned on the DRBD site.
> >
> >    Please let me know the reason behind it.
> >
> >
> >because those results are horribly out of date?
> >note, kernel 2.4 and DRBD-0.6.6 were used for these tests.
> >protocol A and B implementation was broken then.
> >
> >because there are two aspects to protocol choice in DRBD?
> >  * latency
> >  * data safety
> >
> >because you measured throughput,
> >and the choice of DRBD protocol has no impact on sustainable throughput?
> >
> >we realy should take that page offline.
> >or better yet, replace with some more recent benchmarks.
> >I'll try to dig some up.
> >
> >with recent 8.0 resp. 8.2,
> >the protocols finally are implemented correct,
> >and indeed show the expected latency improvements:
> >A exposes nearly local latency,
> >B has some latency overhead (order of round-trip-time),
> >C latency overhead is (order of round-trip-time plus some).
> >
> >as mentioned, you trade data safety against latency.

> I have carried out performance test on 8.0.3 version using Tiobench
> tool. But, results says that Avg latency in case of protocol C is
> less compared to protocol A and B (during write operation),
> theoretically which is not expected.
> Can someone please tell me the reason for it? (refer results given
> below for Sequential and Random writes) 

answer yourself these questions,
and maybe you find the reason for it.

 * why not using DRBD 8.0.11, or 8.2.5
 * what is your kernel
 * what is your storage subsystem
 * what is your io scheduler/elevator
 * what is your file system, if any
 * how does StandAlone DRBD (that is after drbdadm disconnect)
   compare against using that storage directly, without DRBD
 * how does latency change when using
   - no file system
   - different file systems

 * what exact command line did you use for the benchmark
 * how do figures change when
   - using only one thread
   - using a different io scheduler
   - using _synchronous_ writes,
     which is the only thing you should care about for latency of DRBD,
     otherwise you are measuring something completely different.
 * how many DRBD meta data transactions happened during that benchmark run
 * how does statistics change when you operate within the activity log
 * how do latency figures change when measuring with some other tool

: Lars Ellenberg                           http://www.linbit.com :
: DRBD/HA support and consulting             sales at linbit.com :
: LINBIT Information Technologies GmbH      Tel +43-1-8178292-0  :
: Vivenotgasse 48, A-1120 Vienna/Europe     Fax +43-1-8178292-82 :
please use the "List-Reply" function of your email client.

More information about the drbd-user mailing list