On 11/02/14 03:42 AM, Joeri Casteels wrote:
I can cranck up the initial sync to 750MB/s when playing with the c-rate’s
(still not a good performance) while after the initial sync it drops back to
400MB/s
Initial sync is not reflective of real-world performance. In fact, it's
kept low on purpose.
If your DRBD resource (slowest of the network or drives) is, say, 1.1
GB/sec, then that is your _replication_ speed. When both nodes are
UpToDate, your applications using the DRBD resource will work at this speed.
Synchronization speed is the speed at which out of sync blocks are
copied to the peer. So say, for example, your nodes are UpToDate. Then
you disconnect node 2 for a couple of hours and during that time, 50 GB
of data changes on node 1. When node 2 returns, DRBD will start copying
that 50 GBs of changes will start to sync from node 1. This runs at the
sync speed.
If this sync runs at 750 MB/sec, then your apps will feel like their
storage has slowed from 1,100 MB/sec down to just 350 MB/sec (1,1000 -
750). This is rarely what people want, so the best option is to let the
sync operation take longer and let the application speed stay high. The
general rule of thumb is to set the sync rate no higher that 30% of the
tested maximum write speed. This is a good trade off between syncing
quickly without hurting replication performance too much.
Make sense?
Please wait until both nodes are UpToDate and then run your 'dd' test by
writing directly to the /dev/drbdX device (or a file on it's FS, if you
formatted /dev/drbdX). The performance you get with this test will
reflect the performance your apps using DRBD should expect.
--
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?
_______________________________________________
drbd-user mailing list
[email protected]
http://lists.linbit.com/mailman/listinfo/drbd-user
