[DRBD-user] Userspace- vs. Kernelspaceversions

Arnold Krille arnold at arnoldarts.de
Wed Nov 30 19:08:59 CET 2011

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


Hi,

thanks for your quick answer! Any special reason you answered in PM only?

On Wednesday 30 November 2011 17:20:19 you wrote:
> On 11/30/2011 05:03 PM, Arnold Krille wrote:
> > I am a bit stumped currently. Our drbd setup seems to include "extra low
> > performance" as a feature and I don't exactly know where the reason is.
> > On thing the bothers bothers us is that the versions of the userspace
> > tools and the kernel module differ (drbd8-utils v8.3.7 vs module
> > v8.3.9). The newer kernel-module is a side-effect of the kernel from
> > debian squeeze backports needed for the new network-cards. But the
> > versions installed on both nodes are the same.
> > Using latency- and throughput tests from the drbd documentation, the
> > latency rises by a factor of ten and the throughput sinks by a factor of
> > ~5 from the baccking devices to the drbd device.
> What does your drbd config look like? How did you test? What is your
> current drbd state ... cat /proc/drbd?

The config is attached, cat /proc/drbd gives:
root at nebel2:~# cat /proc/drbd 
version: 8.3.9 (api:88/proto:86-95)
srcversion: CF228D42875CF3A43F2945A 
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:147892028 nr:106082524 dw:253754632 dr:50780592 al:770539 bm:5482 lo:0 
pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 1: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:253960 nr:8 dw:8 dr:260076 al:0 bm:26 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d 
oos:0
 2: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r-----
    ns:11942520 nr:12116300 dw:22778044 dr:17360352 al:111558 bm:13501 lo:0 
pe:0 ua:0 ap:0 ep:1 wo:d oos:0
 3: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:112192 nr:1988 dw:114712 dr:1191641 al:89 bm:27 lo:0 pe:0 ua:0 ap:0 
ep:1 wo:d oos:0
 4: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r-----
    ns:29136140 nr:220 dw:29137316 dr:113558985 al:63994 bm:233 lo:0 pe:0 ua:0 
ap:0 ep:1 wo:d oos:0
 5: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:4 nr:385298480 dw:385298484 dr:1896 al:2 bm:32392 lo:0 pe:0 ua:0 ap:0 
ep:1 wo:d oos:0
 6: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r-----
    ns:16 nr:23901960 dw:23902008 dr:1408 al:1 bm:1236 lo:0 pe:0 ua:0 ap:0 
ep:1 wo:d oos:0

 9: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r-----
    ns:0 nr:3145728 dw:3145728 dr:0 al:0 bm:32 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d 
oos:0
root at nebel2:~#

The tests where all run on the resource 9, which is named 'test' and was just 
created for these tests. But all the resources behave the same regarding speed 
and latency:-(

> > So here are my questions:
> >  - Could the mixed version be the reason for the performance penalty?
> No.
> >  - Would it be save to downgrade the kernel (and compile the
> >  network-driver by
> > hand) or is the meta-data on the disk incompatible?
> >  - Or would you rather update the userspace tools to match the modules
> > version?
> I would upgrade drbd module _and_ usertools to latest 8.3.12. ... 8.3.9
> has a know regression that affects small synchronous writes, that may be
> an explanation for the increased latency.

Thanks for that! Upgrading one node didn't yet result in better performance, 
lets see what updating the other gives...

We played with the various buffer parameters to no avail. Modifying al-extends 
on the test-resource on the other hand had rather devastating effects effectivly 
kicking the resources from the machine and therby stopping the VMs on top...

But we managed to pinpoint drbd to be the problem as writing to the underlying 
devices works with 100MB/s while its only 25-30MB/s on the drbd.

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drbd-conf.tgz
Type: application/x-compressed-tar
Size: 1669 bytes
Desc: not available
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111130/e516bf86/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20111130/e516bf86/attachment.pgp>


More information about the drbd-user mailing list