Slow Speeds using UnRaid to UnRaid Syncthing

I am a complete NEWB to Synthing. I have 22TB of data I’m copying from my local LAN to LAN unraid to unraid machines. I am maxing out at 30Mbps and sometimes as low as 200kbps. I have been backing up for over 1 months and still only 25% complete. I have read as much as I can about slow speeds but unfortunately, being a NEWB, I just don’t understand it all. I have read how you can turn off “Enable Relaying” and make sure it’s only using LAN. When I did this, the 2 machines showed as “Disconnected”. They could not find each other. I turned back on relay and worked again.

I have not touched many settings as far as IP or anything in Synchthings. I believe it’s mainly default. I have experience in networking and they are both on the same LAN and even same 1GB Switch. They both have minimum dual 1GB NICs. I can share any screen shots of anything needed to assist.

My goal is simple, I want to have my MAINNAS backup to my BACKUPNAS. I have my MAINNAS set to “Send” and my BAKCUPNAS sent to “Receive”. I want to try to get the network to read LOCAL only and avoid any outside possibilities of slowing it down. Any help is much appreciated.

Which kind of files are we talking about? Sync speed is almost guaranteed to be low for lots of tiny files. Moving Syncthings database[1] to a SSD will greatly benefit performance.

You could also try to disable fsync[2] for the initial data transfer and switch it back on afterwards. Switching it back on is mandatory as this is an “eat-my-data” kind of setting.

[1] Syncthing Configuration — Syncthing v1 documentation [2] disableFsync — Syncthing v1 documentation

Unraid seems to be a RAID 4-like layout with a single parity disk, so will have exceedingly slow writes at the best of times, too.

I am backing up larger files. Currently in the 45+GB range but and as they are re done, it will be smaller files. Nothing less than 400Mb though.

How do I disable fsync[2] and what does that do? Thank you.

Is there a way to make my syncthings static up instead or dynamic? Would that hemp anything?

I have removed parity on the backup machine to remove the possibility of running priory and delaying it. Not sure if that’s correct, but was told to try it.

Notice the link at the bottom of my post :wink:

Got it! Thanks

Do I make the change on just the main server, backup server or both?

The bottleneck is usually the receiving server. All aformentioned tips should be applied at your backup NAS

I have made the Fsync change to no avail. Speeds now at 8Mbps instead of 30Mbps. Are there detailed instructions or videos on how to assign static IPs and how to make sure the MAIN and BACKUP or using LAN only? Thanks

You can check that in the web UI. If the other device connects using TCP to your LAN IP everything is fine.

How’s the CPU and disk IO on the target system?

These are all the target machine.

That’s the first issue you need to resolve then: Get a working connection on your LAN. When the devices are disconnected, there is information about discovered addresses on the remote devices which indicates 1. whether local addresses are discovered and 2. if/what errors there are for those (post screenshots).

Do I disable relaying on the Main, Backup ir both servers? Thanks

I disabled the relay on the main server. Here’s the screen shots.

Simply disabling relays won’t help. Relays are only used as a fallback, when all else is not available. Apparently your connections only work via relay, which means that you probably have an issue with your network.

My network itself is fine. I would agree I have an issue with syncthing network settings. I have no clue what I’m doing. Everything is default. I’m happy to make changes, just need guidance. Thanks

This is from the backup/receiving server. Does this log help? @imsodin @bt90

2021-08-24 16:49:33 addresses: [172.17.255.255]
2021-08-24 16:49:33 recv 157 bytes from 172.17.0.2:58112
2021-08-24 16:49:33 sent 157 bytes to 172.17.255.255:21027
2021-08-24 16:49:44 Connection loop
2021-08-24 16:49:44 Resolved device E4SZJKL-TSLM4NV-GZZZAGI-IGQMN2Q-ATEFOFX-B3IG4XZ-6BCQJJI-XXXXXXX addresses: []
2021-08-24 16:49:44 Next connection loop in 1m0s
2021-08-24 16:50:03 write udp [::]:33543->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 gretap0
2021-08-24 16:50:03 write udp [::]:33543->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 erspan0
2021-08-24 16:50:03 write udp [::]:33543->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 eth0
2021-08-24 16:50:03 addresses: [172.17.255.255]
2021-08-24 16:50:03 recv 157 bytes from 172.17.0.2:58112
2021-08-24 16:50:03 sent 157 bytes to 172.17.255.255:21027
2021-08-24 16:50:33 write udp [::]:52573->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 gretap0
2021-08-24 16:50:33 write udp [::]:52573->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 erspan0
2021-08-24 16:50:33 write udp [::]:52573->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 eth0
2021-08-24 16:50:33 addresses: [172.17.255.255]
2021-08-24 16:50:33 sent 157 bytes to 172.17.255.255:21027
2021-08-24 16:50:33 recv 157 bytes from 172.17.0.2:58112
2021-08-24 16:50:44 Connection loop
2021-08-24 16:50:44 Resolved device E4SZJKL-TSLM4NV-GZZZAGI-IGQMN2Q-ATEFOFX-B3IG4XZ-6BCQJJI-XXXXXXXX addresses: []
2021-08-24 16:50:44 Next connection loop in 1m0s

This is from the MAIN/Sending Server.


2021-08-24 19:09:09 write udp [::]:40512->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 gretap0
2021-08-24 19:09:09 write udp [::]:40512->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 erspan0
2021-08-24 19:09:09 write udp [::]:40512->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 eth0
2021-08-24 19:09:09 write udp [::]:51345->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 gretap0
2021-08-24 19:09:09 write udp [::]:51345->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 erspan0
2021-08-24 19:09:09 write udp [::]:51345->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 eth0
2021-08-24 19:09:16 write udp [::]:55837->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 gretap0
2021-08-24 19:09:16 addresses: [172.17.255.255]
2021-08-24 19:09:16 write udp [::]:55837->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 erspan0
2021-08-24 19:09:16 write udp [::]:55837->[ff12::8384]:21027: sendmsg: cannot assign requested address on write to [ff12::8384]:21027 eth0
2021-08-24 19:09:16 recv 157 bytes from 172.17.0.2:58914
2021-08-24 19:09:16 sent 157 bytes to 172.17.255.255:21027
2021-08-24 19:09:46 addresses: [172.17.255.255]
2021-08-24 19:09:46 sent 157 bytes to 172.17.255.255:21027
2021-08-24 19:09:46 recv 157 bytes from 172.17.0.2:58914
2021-08-24 19:09:57 Connection loop
2021-08-24 19:09:57 Resolved device 66YUU53-UOCN2SL-RYFRVHP-5K4W74V-67TOMUX-NUQZ6WN-FRQEVPW-XXXXXXX addresses: []
2021-08-24 19:09:57 Next connection loop in 1m0s

Seems like the devices are not reporting themselves to discovery, given it cannot resolve any addresses.

Did you mess around with default settings? Those usually just work.

So let’s start network troubleshooting.

  1. Can the NAS devices ping each other?
  2. Is Syncthings port open in both local firewalls?