linenoise Posted January 28, 2016 Report Share Posted January 28, 2016 (edited) I've got what's admittedly a pretty large share, ~38GB, syncing between several Macs and a NAS. 2.3 has been great on the NAS and it works fine on the Macs except the thing is indexing several times an hour and chewing huge amounts of CPU and battery when it does. CPU will peg a core at 100% for 15 minutes at a time and the Energy Impact on my laptops puts BitTorrent Sync as consuming about twice as much power as everything else running on those machines combined. This was a complete non-issue with previous v2.x versions. Is there anything I can provide to help debug? [Here is a possible solution build - RomanZ] Edited February 10, 2016 by RomanZ Added link to possible solution Quote Link to comment Share on other sites More sharing options...
Helen Posted January 28, 2016 Report Share Posted January 28, 2016 linenoise, Yes, you can write to support and submit debug logs from both peers. Also, please describe the share in more details - how many files are there, where they are physically located on each peer. When writing to support, please don't forget to mention this forum topic. So far you can increase rescan interval in Sync settings -> Advanced -> Power user. Quote Link to comment Share on other sites More sharing options...
linenoise Posted February 4, 2016 Author Report Share Posted February 4, 2016 I'm still seeing this with 2.3.1 even after a complete resync of all my data in a fresh folder unfortunately, will submit the logs. Not sure if it's related but I noticed that the resync process from scratch was also VERY slow at times with transfers freezing for over 30 minutes at times despite the machines all sitting on the same LAN at the time. Quote Link to comment Share on other sites More sharing options...
sc Posted February 5, 2016 Report Share Posted February 5, 2016 I am experiencing the same issues on OSX. We have large amount of files (200 Gb divided in about 20 folders for a total of 300k files). It's important to mention that the previous version with the same amount and type of data after the obvious CPU time needed during the startup phase, everything was calming down very quickly and running smooth. Quote Link to comment Share on other sites More sharing options...
ekim501 Posted February 6, 2016 Report Share Posted February 6, 2016 I’m also experiencing this problem on my systems. I have a Windows 7 and Windows 10 system and they are both running BTSync slower. With 2.2.7 after booting the system up or waking it from being a sleep the system would transfer the files almost immediately with no system lag. With 2.3.1 – it takes about 10 min after waking the system for it to start transferring the files – and it uses a lot of CPU. I ended up downgrading to 2.2.7 and the issues went away. Quote Link to comment Share on other sites More sharing options...
linenoise Posted February 10, 2016 Author Report Share Posted February 10, 2016 Got this sorted, or at least worked around via support. Under Options > Preferences > Advanced > Open power user preferences I was advised to set the folder_rescan_interval to 0, turning it off entirely. Behaviour of BitTorrent Sync seems identical in my use case and the CPU usage is the best I've ever seen it. That said, there's a definite increase in usage between 2.2.x and 2.3.x that's apparently being looked at. Quote Link to comment Share on other sites More sharing options...
Helen Posted February 10, 2016 Report Share Posted February 10, 2016 @all, Here are Windows32, Windows64 and Mac builds with a fix for that problem. Try them, and see if the problem is solved. If not, please submit logs to support as was mentioned above. Here are linux binaries: arm armhf i386 x64 glibc23_i386 glibc23_x64 Quote Link to comment Share on other sites More sharing options...
linenoise Posted February 11, 2016 Author Report Share Posted February 11, 2016 Thanks Helen, I'll give this a shot for you ASAP. Awesome to see the quick turn around on this btw. Quote Link to comment Share on other sites More sharing options...
Manuel Sosi Posted February 14, 2016 Report Share Posted February 14, 2016 Hey there, I have the same problem, I'm trying right now the build you linked, I'll let you know Quote Link to comment Share on other sites More sharing options...
stijnos Posted February 14, 2016 Report Share Posted February 14, 2016 Are the NAS packages updated too? 2.3.1 is not stable on my Synology (x64) Quote Link to comment Share on other sites More sharing options...
linenoise Posted February 14, 2016 Author Report Share Posted February 14, 2016 Looking remotely, no luck with the new build. Behaviour looks the same to me. Will get you some logs. Quote Link to comment Share on other sites More sharing options...
Helen Posted February 15, 2016 Report Share Posted February 15, 2016 stijnos, No, NAS packaged are not updated. Try the necessary build, if it fits your NAS architecture, and replace it in package, or launch manually. Quote Link to comment Share on other sites More sharing options...
stijnos Posted February 15, 2016 Report Share Posted February 15, 2016 3 hours ago, Helen said: stijnos, No, NAS packaged are not updated. Try the necessary build, if it fits your NAS architecture, and replace it in package, or launch manually. Thanks, gonna try this :) Quote Link to comment Share on other sites More sharing options...
alexisargyris Posted February 15, 2016 Report Share Posted February 15, 2016 I'm sharing around 10GB among macs, windows and a NAS (drobo). I get (again) constant, very high CPU on the mac. The windows machines are normal, but didn't have this problem anyway. Quote Link to comment Share on other sites More sharing options...
Helen Posted February 16, 2016 Report Share Posted February 16, 2016 On 2/10/2016 at 4:19 PM, Helen said: Here are ..... builds with a fix for that problem. Try them, and see if the problem is solved. If not, please submit logs to support as was mentioned above. Thank you! Quote Link to comment Share on other sites More sharing options...
alexisargyris Posted February 16, 2016 Report Share Posted February 16, 2016 where are the builds? Quote Link to comment Share on other sites More sharing options...
Helen Posted February 17, 2016 Report Share Posted February 17, 2016 a few posts above. the link to then is available in the starter port, here it is Quote Link to comment Share on other sites More sharing options...
Vondo Posted February 17, 2016 Report Share Posted February 17, 2016 2.3.1006 did not help me. I keep about 2 TB in sync across 10-11 shares and Sync was constantly running at 100% for days. I downgraded to 2.2.7 and it's fine now. Quote Link to comment Share on other sites More sharing options...
alexisargyris Posted February 17, 2016 Report Share Posted February 17, 2016 2.3.1006 is the version i used when I reported on Monday that my mac was not helped and continues to run at 100%. Quote Link to comment Share on other sites More sharing options...
Helen Posted February 18, 2016 Report Share Posted February 18, 2016 Some more discovered causes are fixed. Download is available in this topic: Again, anyone, who 2.3.2 doesn't help, please write directly to support and submit the logs from the affected machine to them, here's instruction to collect the logs. A few details about your setup - files' number and their physical location on the computer will be of use. Thank you! Quote Link to comment Share on other sites More sharing options...
jpap Posted November 5, 2017 Report Share Posted November 5, 2017 I also had high CPU utilization on two macOS machines, one being a MacBook 12" (2017) which was overwhelmed by Resilio Sync. I am managing just two folders, but each has 1,654,405 files combined, over many sub-folders. Sync was not transferring files despite the high CPU: all files were in a synced state. It turns out that Sync was periodically re-scanning all of the files/folders every 10 minutes! After disabling this, using the "power user preferences" option "folder_rescan_interval = 0", the high CPU usage disappeared completely on both machines. Sync was still able to detect changes to each folder. I suspect they are using the macOS FSEvents APIs where the OS tells Sync which files have changed without polling. I would love to know why the folder_rescan_interval isn't set to 0 on macOS by default? (And Windows, where I'm guessing the equivalent Windows Change Journals are being used?). Quote Link to comment Share on other sites More sharing options...
Helen Posted November 8, 2017 Report Share Posted November 8, 2017 rescan isn't set to 0 by default, cause Sync actually needs rescan. Here's the link to collect logs:https://help.getsync.com/hc/en-us/articles/206664730-Collecting-debug-logs- Send them to support. Thank you! Quote Link to comment Share on other sites More sharing options...
jpap Posted November 9, 2017 Report Share Posted November 9, 2017 @Helen, that's interesting -- any idea why Sync doesn't need a rescan on macOS? Thanks for the link to the debug log collection. Quote Link to comment Share on other sites More sharing options...
Helen Posted November 9, 2017 Report Share Posted November 9, 2017 4 hours ago, jpap said: any idea why Sync doesn't need a rescan on macOS? I was saying it needs rescan. so I cannot answer "why it doesn't need it" Quote Link to comment Share on other sites More sharing options...
jpap Posted November 9, 2017 Report Share Posted November 9, 2017 Just now, Helen said: I was saying it needs rescan. so I cannot answer "why it doesn't need it" Any idea why "it (Sync) needs a rescan" on macOS? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.