i just noticed something for the third time or so:
I am currently syncing several folders.
Since the process was so slow, i paused all in-progress folders except one.
In that moment i noticed the following:
The UI froze for like 10 or more seconds when i hit pause on one of the folders (lot’s of files in there: 895.834, dirs: 16.857, 68GB)
p.s. In my case i have all the data already in another (huge) folder present on the target machine. So ST merely copies data from one folder to another without much network traffic.
The connection to the other device was terminated.
This message happened thousands of times in the logs (for different files):
[DEVICE-ID] 08:07:15 INFO: Puller (folder “MY-FOLDER” (MY-FOLDER-ID), item “PATH-TO-A-FILE”): no connected device has the required version of this file
And I got the notification in the GUI:
Decoding posted config: read tcp 127.0.0.1:8384->127.0.0.1:55261: i/o timeout
The folder which is still active now shows as “Failed items” instead of “Synchronizing”, but from the file details i can tell it is still syncing.
Version: v1.3.0, Windows (64 bit) with Synctrayzor
Debug-Logs are all disabled.
I am not sure why the GUI is locked up, but others are expected.
Syncthing needs to re-establish connections after pausing the folder, which means temporarily there will be no availability of the files, which means you’ll have failed items.
It looked to me as if all still to be synchronized items were printed to the log. In my case (when i activated all folders) several million files (with long names/paths).
Maybe you should disable this puller log message by default.
Or even better stop pulling when the device is disconnected, until it is reconnected.
I checked the logs. The first occurrence i found had 641 Log entries printed in 1 second. The log file had 176000 lines of which almost all are this puller error. And this is just one log file.
I have millions of unfinished files. You should really do something about this logging and/or pullers attempting to download when no other devices are connected.
I have huge log files and lots of wasted CPU time and HDD writes due to this:
I would even go so far as to say this is one of the main reasons why ST slows PCs unnecessarily.
As I explained this is intended. The fact that one file is not available does not mean others are not, hence each file needs to be handled individually.
I am not buying writing a few megabytes of text slowing PCs down argument.
Regardless of performance I agree it’s excessively verbose to log an error for every single out-of-sync item, especially if it’s the same error. We could do something like after printing *insertMagicNumber* sync errors, print an error saying that tons of sync errors occurred, you should check UI or rest if you want all of them. Also we could be smart and not print errors if we already printed an error for the parent (e.g. permission denied) - that would probably even make the actionable problem easier to spot for the user. More or less what I am saying while it is working as intended at the moment, I do believe there is room for improvements (while that’s true for a lot of things).
Agree. With the caveat that this must be possible to turn off, because I have deployments that depend on the traceability of being able to grep for a filename in the logs weeks later and see when and how it failed to sync or not.
Reporting every error once and then on next pass just saying “… and 1234 errors reported previously” would be fine but requires keeping a shitload of state.
Sure, it adds a few megabytes to the log, but who cares, storage is cheap, and making debugging 10000x harder for the purpose of saving 3mb is really silly.
The OPs claim is that things are slow, which I disagree with as the claim is unjustified.
Sure, the OP is annoyed that we produced a lot of errors and that blattered stuff into the log, and temporarily spiked cpu usage while we churned through the queue, yet that has nothing todo with slowness or how many log lines we logged.
Even if we log less we’ll still churn through the queue repeatedly until we run out of attempts.
I don’t think there is a good way to fix this without giving up retrying stuff all together.
I mostly agree. If we can reduce needless repetition in the logs then that makes them more human readable and that is good. It is not a performance issue.
I am still having massive problems with performance.
As suggested in another Thread some days ago i use SyncTrayzor now.
SyncTrayzor freezes its UI regularly whenever Syncthing starts logging a lot.
And with a lot i mean when i pause a folder or a device or when i save any setting of a folder syncthing disconnects from all devices and then the puller walks through all (unfinished?) files and prints them in the logs.
syncthing creates about 50MB of logs in pretty exactly 1.5 Minutes:
syncthing.0.log: 10:56:36 - 10:58:06
syncthing.1.log: 10:58:06 - 10:59:37
syncthing.2.log: 10:59:37 - 11:01:07
I would like to disable logging all together to see if this helps solve the performance problems, but i could not find a setting for that.
Is there an option or switch somewhere to disable logging completely?
p.s. i still think the puller should pause when there are no connected devices.
The log mostly/only contains this log message: [3LGK7] 11:01:07 INFO: Puller (folder “FOLDER-NAME” (FOLDER-ID), item “FILE-NAME”): no connected device has the required version of this file
I was adding and configuring 10 new folders. Until all is set up correctly i have to do many changes in the settings.
The next thing was that it seemed to me the HDD was too busy when processing 10 folders in parallel thus i decided to disable 9 of the 10 folders and let the one sync 100% before enabling the next one.
