[DRBD-user] syncer speed

[Sebastian Riemer]

Hi,

there is an IO request size bug in < 8.3.14 and < 8.4.2. That version
model doesn't support pushing stuff to linux-stable.

See this for details:

http://www.gossamer-threads.com/lists/drbd/users/24104

http://git.drbd.org/gitweb.cgi?p=drbd-8.3.git;a=commit;h=3a2911f0c7ab80d061a5a6878c95f6d731c98554

Cheers,
Sebastian


On 24.12.2012 19:00, Digimer wrote:
> On 12/24/2012 05:48 AM, Walter Robert Ditzler wrote:
>> hi to all,
>>
>> is there anyone who has experience in speed allocation for a double 10gbit/s
>> 10gbase bounded with bound type 3?
>>
>> i configured ...
>>
>> ***
>> syncer {
>>     al-extents            31;
>>     rate                     450M;
>> ***
>>
>> ... but get back a copy speed of a 800mb dummy file of 46m/s.
>>
>>
>> any help appreciated :-)
>>
>> happy x-mas,
>>
>> walter.
> 
> First, confirm what speed your network can sustain on it's own. Use
> 'iperf' if you can, it's my go-to tool for network performance testing.
> Next, break out one of the backing storage devices, put a normal FS on
> it (like ext4) and use something like bonnie++ (and be sure to set a
> test size that is 2x your RAM) to test the bare storage maximum
> sustained throughput.
> 
> Once you know how fast they are on their own, take the slower of the two
> and that is the theoretical maximum speed that DRBD will achieve.
> Generally, I set the 'syncer { rate xxM; }' to ~30% of that speed. If
> you set syncer to be too fast, your normal I/O will suffer as the
> background syncing will consume all your available bandwidth. This is
> why the sync rate is set low by default.
> 
> If you set the  'syncer { rate xxM; }' to a speed higher than is
> actually possible, it could actually hurt performance and, possibly,
> stall the sync entirely.
> 
> To be clear;
> 
> The syncer rate is *not* the day to day performance speed. Normal I/O,
> like writing a file to the FS on the DRBD resource, will always go as
> fast as is possible. The syncer rate *only* effects the speed at which
> out-of-sync blocks are copied over when one of the nodes has been
> off-line and blocks changed on the remaining peer,
> 
> digimer
>