[DRBD-user] Performance issue

Maros Timko timkom at gmail.com
Mon May 17 00:32:34 CEST 2010

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


First of all, don't expect a lot of replies. Rather try to search in
the mailing list archive for some optimisation proposals.

> Hello,
> I'm trying to optimize write performances on a primary/primary drbd cluster.
>
> The nodes are connected directly with a dedicated gigabit network.

1024b/8b = 128B/s
So this is your maximal _theoretical_ one-way network transfer rate.

>
> To get rid of filesystem perfs, I'm adressing the drbd ressource directly.
>
> Here's what dd gives me (I'm using one big chuck to get rid of latency) :
>
> # dd if=/dev/zero of=/dev/drbd0 bs=512M count=1 oflag=direct
> 1+0 enregistrements lus
> 1+0 enregistrements ?crits
> 536870912 octets (537 MB) copi?s, 30,3065 seconde, 17,7 MB/s

At the first sight it looks a bit smaller then expected, but still not that bad.

>
> Now, I disconnect the ressource :
> # drbdadm disconnect r0
>
> And I have very better perfs :
> # dd if=/dev/zero of=/dev/drbd0 bs=512M count=1 oflag=direct
> 1+0 enregistrements lus
> 1+0 enregistrements ?crits
> 536870912 octets (537 MB) copi?s, 8,6145 seconde, 62,3 MB/s
>

OK, when DRBD is disconnected it does not bring a lot of penalty, but
still there is some. I would roughly say 5%. As a consequence, ask
yourself what kind of write rate can provide your system for local
writes to a raw device (not to writes cache).
BTW - if you want to claim - can you provide results of the same test
against raw device with "oflag=direct"?

> When syncing, I get :
> finish: 3:07:23 speed: 61,240 (55,320) K/sec
>
> Which seems around the real performance.
>
> The version is :
> version: 8.0.16 (api:86/proto:86)
>
> Do you have any clue about what is giving me this 3.5 factor ?

Sure, just imagine what DRBD needs to do to ensure your data
consistency across cluster nodes:
 - do local write
 - send the write update of the whole data blocks to standby node
 - wait until stanby acknowledges the write there (real write)
 - update local metadata (another local write)
 - a lot of operations and computations in between

The magic behind DRBD uncovers your understanding of the level of
optimisation that your system can do for you if it does not care about
outside world interactions (kernel, system RAID level, disk caches,
...)

Please be gentle, I'm still learning.

>
> What other information can I give you ?
>
> Thanks for your help,
> Julien Escario



More information about the drbd-user mailing list