[DRBD-user] drbd 0.7.4 half the speed of 0.6.13

Josh McAllister josh at bluehornet.com
Tue Sep 21 23:22:02 CEST 2004

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... THANK YOU, MAJOR improvement:
0: cs:SyncSource st:Secondary/Secondary ld:Consistent
    ns:7376452 nr:0 dw:0 dr:7377568 al:0 bm:449 lo:0 pe:916 ua:279 ap:0
        [===>................] sync'ed: 16.6% (36391/43591)M
        finish: 0:09:26 speed: 65,660 (55,432) K/sec

Based purely on perception (I haven't actually timed full sync with both versions -- but I could if it would be useful) though the number reported (55,432) is still 30% less than it was with 0.6.13 it seems to be performing on par. Could it be that the calculation for the average rate is a bit more accurate/different in 0.7.x?


With that out of the way, a couple more observations on this issue:

1. With max-buffers/max-epoch @ 256/256 as it was, sync rate was about 48MB/sec. 2048/2048 gave about 52MB/sec. 1024/2048 yielded the result posted (55MB/sec). This seems more sensible.

2. I've done some additional performance testing with bonnie... some potentially interesting results below. Looks like 0.6.13 is still faster overall, and neither is even half as fast as direct device. Is this not an accurate measure?

Thanks again,

Josh McAllister

----------------------------------------------------------------------

Test physical device:
[root at cluster3-1 bonnie]# ./Bonnie -d /mnt/sdc -s 2000
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
         2000 45349 99.6 89333 19.1 72308 12.2 49221 100.0 1807429 99.7 110038.2 275.1


Test same device with drbd-0.6.13 on top:
[root at cluster3-1 bonnie]# ./Bonnie -d /mnt/drbd -s 2000
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
         2000 40073 97.7 42387 15.0 36455 12.1 47930 99.7 1851980 99.5 114972.3 287.4


And with drbd-0.7.4-patched:
[root at cluster3-1 bonnie]# ./Bonnie -d /mnt/drbd -s 2000
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
         2000 41623 97.6 35344 12.4 30179 10.0 48180 99.9 1809553 99.8 108867.2 272.2

-----Original Message-----
From: drbd-user-bounces at linbit.com [mailto:drbd-user-bounces at linbit.com] On Behalf Of Philipp Reisner
Sent: Monday, September 20, 2004 3:56 AM
To: drbd-user at linbit.com
Subject: Re: [DRBD-user] drbd 0.7.4 half the speed of 0.6.13

[...]
> I've tried a plethora of different max-buffers / max-epoch values,
> starting with 2048/2048, and ending up at 256/256 as this improved
> performance from about 20MB/sec to about 28MB/sec. Still no where near
> the 73MB/sec I can reliably obtain using 0.60.13

Lars already posted the patch that should fix this issue (please
report success or no success, so that we can include this patch
into the next upstream release)
And I really want that drbd-0.7 will sync at least as fast as drbd-0.6.

On the other hand I want to point out that a lower sync rate should
not be a real issue. drbd-0.7 will only sync the amount of data covered
by the AL, while drbd-0.6 will sync the whole device after a primary
crash. This gives that drbd-0.7 will finish the sync process faster
than drbd-0.6 anyway (if your device is considerabely bigger than the
area covered by AL).

[...]
> Please help! I'd like to be able to take advantage of the added benefits
> of 0.7.x, but this is for a DB server that is already I/O constrained...
> I can't afford to take this kind of performance hit.

Just to make it more clear. This "sync performance" only applies to 
the resync process (and you should _constrain_ it to _not_ use 100%
of your overall IO performance). It does not affect the perfomance 
during normal mirroring operation (cs: connected)

-philipp
-- 
: Dipl-Ing Philipp Reisner                      Tel +43-1-8178292-50 :
: LINBIT Information Technologies GmbH          Fax +43-1-8178292-82 :
: Schönbrunnerstr 244, 1120 Vienna, Austria    http://www.linbit.com :
_______________________________________________
drbd-user mailing list
drbd-user at lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user




More information about the drbd-user mailing list