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, Nov 15, 2011 at 05:40:31PM -0700, David Mohr wrote:
> Hi,
>
> after successfully upgrading from 8.3.7 to 8.3.12 (thanks again for
> the help from the list), we notice very slow sync speeds:
>
> $ cat /proc/drbd
> version: 8.3.12 (api:88/proto:86-96)
> GIT-hash: e2a8ef4656be026bbae540305fcb998a5991090f build by
> root at s1a, 2011-11-15 22:13:28
> 0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C
> r-----
> ns:0 nr:2466144 dw:2466144 dr:0 al:0 bm:663 lo:0 pe:6241 ua:0
> ap:0 ep:1 wo:b oos:1039000
> [========>...........] sync'ed: 49.0% (1039000/2031448)K
> finish: 0:03:39 speed: 4,728 (6,616) want: 51,200 K/sec
>
> This is on a direct trunk between the two machines. With 8.3.7 we
> could increase the sync speed to 120M/s and drbd would use it full
> speed. We didn't change anything aside from drbd kernel module and
> userland.
>
> Any pointers?
c-min-rate (is active by default, even if the other c-* are not)
defaults to 4M.
Now, what does that mean?
more recent DRBD supports a "adaptive dynamic resync rate controller".
The basic idea is that it tries to detect "application activity"
on the device, which includes both read and write on the lower level
device which can not be accounted for by the resync internal requests.
If it detects application IO, and the current resync-rate is above
c-min-rate, it will throttle resync to lessen the impact on application
request latency.
To disable: c-min-rate 0; (syncer section).
To tune: up c-min-rate to something where it starts to impact
application request latency, then go back down slightly.
Think of the equivalent of "wondershaper" for DSL modems, which
throttles the downlink just so much that it won't impact the uplink
or latency ;-)
The rest of the "c-*" parameters need to be enabled explicitly
(by setting c-plan-ahead to != 0).
Algorithm is then
try to reach (no more than) c-max-rate, but throttle if
* application IO is detected,
and current estimated rate is > c-min-rate
(same as explained above)
* c-fill-target = 0, and the current estimated request roundtrip
latency exceeds c-delay-target (which is > 0)
* c-fill-target > 0, and the current amount of in-flight requests
to the peer exceeds c-fill-target. (c-delay-target ignored)
This is to try to use up as much "idle bandwidth" for the resync as
possible, while at the same time minimize the impact on application IO.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com