Sync 2.6.2-1330 (Windows) - seems like 1 thread always busy (causing 25% cpu usage)

[luckman212]

I have a 2-core VM running Rslsync 2.6.2-1330 on Windows Server 2012. Sync is set up to run as a Windows service.

Not sure when it started, but I have noticed now that Resilio Sync.exe is constantly keeping the CPU at 25-50% usage. I am talking about endlessly... for 24 hrs+. I have enabled debug logging and looked at the log file, there's lots of stuff but not really any errors, warnings or failure messages. Sync is working fine, etc. Just that the CPU is being heavily hit and not sure why (this is even when no filesystem changes are occurring).

I have tried the usual stuff— restarting the machine, giving it more memory (it has 16GB allocated now, and only ~3GB in use), and stopping/starting the sync service.

Is there any way to debug this further to figure out what is causing the CPU load? I tried running SysInternals Process Explorer and viewing the threads but without the debug symbol files for rslsync I can't really "see" what the threads are so busy doing.

[luckman212]

Today I noticed that there was a "Disk" tab in the lower left of the Rslsync stats area, so I clicked on it and saw that the "Disk" was hovering at >90% endlessly. I checked in Task Manager to see if that matched up. It didn't - according to Task Manager, the C drive was basically idle (0-1%).  So, not sure where this phantom activity is coming from.  Is Rslsync doing a re-index of a network share and counting this as "Disk" access? That's the only thing I can think of, since my shared folders are all on mapped drives.

Again I don't know how to tell from looking at this what it's doing -- the logs don't clearly indicate it either.

[Frank Maier]

  Resilio Sync is re-indexing all files preiodically, in the case of some missed files. If your machine is slow and you have many files, thus it didn't finish after 10 Minutes, then it's busy all the time

https://help.resilio.com/hc/en-us/articles/205458185-Setting-how-often-Sync-should-check-for-file-changes-

You can change it to maybe 1 hour or more, depending on your personal needs. 

[luckman212]

Thanks, I guess there are too many files like you said, and the background indexing is just never completing. I'll try setting it to 1 hour and see.

I am realizing that the main problem is that due to all the files being on a Synology NAS that is accessed over SMB from the Windows machine that has Rslsync running. So Rslsync isn't getting filesystem change notifications, and relies 100% on the background scan to detect changes.

I tried running the Sync package directly on the Synology, but the CPU on the Synology was just too weak to handle this many files. Thus we moved to the Windows server but kept the files on the NAS.

Now I guess the "real" solution will be to eliminate the NAS and move the storage locally to the Windows server.

[Frank Maier]

Or don't use SMB but iSCSI instead and let the Clients connect to the Windows Server via SMB instead of to the NAS.

[luckman212]

So far, setting the resync interval to 3600 is at least allowing the background scanning to finish. The iSCSI option is definitely a possibility but since it requires moving all the files, reformatting the storage etc that's going to have to wait. This works for now.