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, Sep 11, 2012 at 02:23:01AM -0700, lucas.l wrote: > ---- 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. Then maybe your devices are simply too small for the various averaging measurements to kick in and do the appropriate throttling. If that is the case, and it is important for you, contact LINBIT directly, we should be able to fix that for you. > > 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. Just checking ;-) -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.