I have a repo that is aprox. 117000 files at 11Gb. ON a Gig E network this should only take a few hours but it has been running for days. This same folder was being synced by BTsync and it only took about 4 hours to sync it.
Any help would be appreciated.
Having Web UI is known to have an effect on the transfer speeds, hence I suggest you check the transfer speed shown in the UI, then close the UI, let it settle and see if the transfer speed improves via some other external utility which doesn’t involve opening the UI.
after closing the web ui on both computers it finished in a matter of mins. is there any plans to fix this?
I personally cannot seem to reproduce it as it’s machine dependant, though I’d love to fix it.
Can you do me a favor, and just try opening web UI on either side to work out which side slows down the transfer with the UI open? Is it the sending side that’s causing it or the receiving side?
I have tried it both ways and it seems that it may be an issue with the Freenas version of Syncthing.
Wen syncing any files form there it is slow with gui open. but if i have 2 windows nodes syncing directly it is preaty fast.
Well, because freenas is as powerful as a calculator I guess. It would never the less be interesting to see a CPU profile of the freenas device to see where most of the time is spent.
Well my freeNas is preaty beefy. it is 2 Xeon E5-2620 v2 and 64gb ram
Can you copy the full version (machine where build, versoin of Go, arch etc) line from the console log? Would you be interested in running a debug build to help and track this down?
i would be happy to give the info needed if you can provide commands you would like me to run. in regards to using a dev build this is a production server and i cant risk it.
I think @AudriusButkevicius means the first couple of lines of the Syncthing log output when you start Syncthing.
Eg:
[TBQ3X] 11:34:03 INFO: syncthing v0.10.9 (go1.3.3 windows-amd64 default) unknown-user@syncthing-builder 2014-11-30 12:45:08 UTC
[TBQ3X] 11:34:03 INFO: My ID: T....
[TBQ3X] 11:34:03 INFO: Starting web GUI on http://127.0.0.1:51118/
[TBQ3X] 11:34:03 INFO: Starting UPnP discovery...so how would i get that log since this is running in a jail on freenas?
I am not sure how syncthing is packaged in the NAS repo, but I would just try to invoke the binary manually.
I just started running Syncthing today between my FreeNAS mini and my laptop.
I transferred a few gigs in both directions and noticed this happening when the web interface on the FreeNAS is up.
CPU usage goes from ~75% to 200% and Network usage drops from ~17Mbps to almost nothing on the FreeNAS. I also noticed that the web interface on the FreeNAS is a little more chatty than on my laptop; it constantly asks for the model of the (only) folder I’m syncing.
Laptop: syncthing v0.10.18 (go1.4 linux-amd64 default) builduser@flexiondotorg 2015-01-06 22:12:40 UTC FreeNAS: syncthing v0.10.14 (go1.3.1 freebsd-amd64 default) root@freebsd-ports 2014-12-30 02:39:28 UTC
From what I can tell, the Syncthing plugin doesn’t write the console log to a file. On my FreeNAS, I invoked this binary just to get read the first line in the console, then killed it.
/usr/pbi/syncthing-amd64/bin/syncthing
It logs to stdout/err
Slow when the web gui is open is a known issue, that seems to present mostly on freenas and raspberrypis. 
I’m seeing the same issue with the v0.10.23 release. Both machines are running Windows Server 2012 R2.
The shared folder has about 48,000 files (10 GB).
When the web UI is open in Chrome, it transfers VERY slow – about 1 small file every 10 seconds. When the Web UI it’s closed the transfer goes very fast.
What’s strange is that I first shared a smaller folder with about 4800 files (600 MB) and that transferred quickly, even with the Web UI open. Then, when I shared the second, larger folder it slowed to a crawl.