I have two colo servers, each on 1Gbps pipes. Site A is 2012 R2, Site B is Ubuntu 16.04.1 LTS. Between them has 7 different folders shared. It is a one-way relationship: B syncs to A, never A to B.
When a file is synced across B->A, it seems to hit an invisible 100Mbps(11.6MB/s) barrier. I check with DUMeter and the bw is flat, so something is limiting it.
When multiple folders have files to be synced, the speed is a multiple of the folders syncing. For example, if I add a new file to 3 different shared folders, the total sync speed sits right at 300Mbps.
Then I tried initiating a single SFTP download A<-B, and it reaches a speed of ~220Mbps, with some slight variations. I believe this to be a more accurate representation of the raw maximum bandwidth available per thread.
I checked Syncthing’s settings/advanced settings, the maxRecvKbps and maxSendKbps are set to 0. I didn’t see anything else that might refer to limits or buffer sizes. Is there anything else I can check?
Try increasing number of pullers per folder, also check for CPU usage which can be a limit for crypto.
Hm. Tried upping my test folder pullers to 5 but there is no change, still resting at the 100Mbps plateau.
Load average on the sender Site B is: 0.79, 0.37, 0.19
The receiver Site A was minimal/idle cpu usage.
You need to set it to like 100
oh, lol! I wasn’t sure what the original value actually was when it’s just 0.
OK changing to 100 did it - it’s now peaking at 580-600Mbps on a single folder. Thanks for the help!
There is already the automatic selection of the right / fastest hashing algorithm. Might the number of pullers also be something worth considering for evaluation during startup?
It seems there is a big difference for some people.
You can’t evaluate it meaningfully without having somewhere to send data, furthermore for some connections it might be damaging rather than beneficial, yet I think we should potentially double the default.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.