Just would like to understand what kind of memory usage to expect when syncing 1TB with 700k+ files.
The initial folders at both machines where almost identical and the 50Gbyte that needed to be synced is making good progress (syncing is at 40%).
I’m using v0.11.17 and syncthing memory usage on the machine that needs to receive files is up to 789MByte.
Syncthing on the machine that sends the files only needs 433 MByte memory.
Reading the forum I expected that after the initial scan the memory would drop to 150MByte but its still going up.
Or is the memory only going down after the first complete sync?
Restarted with activating the UI, again a crash
Restarted without activating the UI, seems to run fine with about half the memory (400MBytes)
Someone interested in the log file of the crash?
New users can’t attach and the log file is too big to include in message
Can download from here
Sync is at 100% now scanning, left for some time without UI, restarted the UI
Now 675MByte memory used.
It looks like a golang runtime bug. I doubt it has anything todo with the fact you have UI enabled or not, and is probably not related to ram. What version of windows are you running?
Judging from the build tag, it seems like it’s the standard build we provide, but I’d like to double check if that is the case?
Also, the log seems interleaved (for if you search for goroutine 94 it actually comes up twice).
Can you try running vanilla syncthing, and see if that still happens, and if it does, get a non-interleaved log?
There should also be a log file in syncthing’s home directory which is captured by syncthing (rather than synctrayzor)
I’m running the official syncthing 0.11.17 on uptodate windows 7.
The log file came from the log folder underneath the home directory of the syncthing executable
Would the interleaving indicate I’ve been running syncthing twice? Is that possible?
There is something weird as the replication process has produce till now 300000 files conflicting copies in one folder, 8 conflicting copies of each original file in the folder.
So I stopped syncing as you can imagine.
Will do a restart of the syncing tomorrow as the replication target is being used for more important stuff (watching TV series)
So there is something really weird going on. So just to get things straight, you do seem to be using synctrayzor by @canton7. If the file you’ve provided is you think syncthings log, then I have to tell you that it is not (as it got a few of Syntrayzor’s log lines).
Syncthing by itself also generates a log on windows (if you use it without synctrayzor), which is the one I am interested in.
Alternatively, you can invoke syncthing by itself, enable a fair share of scroll-back buffer in the command prompt, and try triggering the crash (so I could submit it to golang devs).
Alternatively, if you open up command prompt, and check -help for syncthing, it will tell you it’s home directory, which is where the log will be (make sure it’s not the database log, but the same log you get in the command prompts buffer).
Regarding the conflicts, it could happen if you zapped the database between the syncs, or if you
have some funky backing storage (samba sometimes does it) which does not preserve modification timestamps.
That unexpected signal during runtime execution stuff is a Go bug, for what it’s worth. It should be filed, if it isn’t already… Although a reproducer will probably be necessary to get it fixed.
Using plain syncthing everything did run well.
Total memory used peaked at 780MBytes, went down to about 150MBytes after 30 minutes
Topic can be closed (unless someone comes with a solution for substantial less memory usage)
SyncTrazyor won’t affect the memory that Syncthing uses (very much) - the two run as independent processes. If Syncthing is now using less memory on its own, it will use less memory when running inside SyncTrayzor.