Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
---- On Tue, 11 Sep 2012 01:44:59 -0700 Lars Ellenberg<lars.ellenberg at linbit.com> wrote ---- > On Thu, Sep 06, 2012 at 04:26:30AM -0700, lucas.l wrote: > > Hello, > > we've got a drbd-8.4.1 installation running in a custom HA setup. The > > controllers are connected via a 100M Ethernet link with an Ethernet > > switch. In order to keep our services responsive, we need to keep the > > resources' usage low during initial/full synchronization. We've tried > > a fixed resync-rate as well as the dynamic sync rate controller to set > > the maximum resync speed at 1M. We also gave drbd-8.4.2rc3 a try and > > still failed to achieve the goal. Here is our DRBD configuration: > > > # cat /proc/drbd > > version: 8.4.2rc3 (api:1/proto:86-101) > > GIT-hash: f25fbeaaf922cb91e33a9c2eb99560473b0b2122 build by build at lnxdev, 2012-09-05 15:40:38 > > (...) > > 5: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r----- > > ns:0 nr:38912 dw:38912 dr:0 al:0 bm:5 lo:0 pe:0 ua:0 ap:0 ep:1 wo:d oos:1024 > > [===================>] sync'ed:100.0% (1024/39936)K > > finish: 0:00:00 speed: 5,556 (5,556) want: 1,024 K/sec > > Do I understand correctly that all you are complaining that the *reported* > average resync speed is faster than the configured maximum? Yes, we need to limit the maximum resync rate but the actual resync is done at full speed. > > Is this also the case for larger resyncs (full syncs)? Yes, this is the full-resync case. > Is this also the case if the device is idle, application wise? Yes, this behaviour is also true while our services are down and no I/O requests are being issued. I understand that DRBD's resync rate controller works only for the initial sync and when it's done everything is up to us. It seems that is not the case here. > > Do you experience performance degradation for your application? Yes, we observe serious performance degradation with drbd syncing at full speed. Our services can issue some (small) writes but a single fsync call can take ten-odd seconds. Everything is back to normal when initial sync is done. > > Are you aware that, with DRBD Protocol C, an application write > do a no-in-sync block will also bring this block in-sync, > and thus count to the resync rate -- which "measures" how many > blocks per unit time change from "not-in-sync" to "in-sync"? Yes. > > Lars > > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > Thank you for the reply. Best regards, Lucas