xiaoyu Posted July 10, 2016 Report Share Posted July 10, 2016 Not sure if others have the same problem, but my FreeBSD Sync installation always takes 100% CPU load after it's running for a while. The web UI can't be loaded at all. I've already upgraded Sync to 2.3.8 In top it shows PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 79970 btsync 7 22 0 1065M 809M umtxn 3 553:54 100.00% btsync umtxn means Kernel Lock. So I ran # procstat -k 79970 PID TID COMM TDNAME KSTACK 79970 100367 btsync - mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 79970 100592 btsync - mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 79970 100594 btsync - mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep kern_kevent_fp kern_kevent sys_kevent amd64_syscall Xfast_syscall 79970 100602 btsync - mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 79970 100603 btsync - mi_switch sleepq_catch_signals sleepq_timedwait_sig _sleep umtxq_sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 79970 100605 btsync - <running> 79970 100607 btsync - mi_switch sleepq_catch_signals sleepq_wait_sig _sleep umtxq_sleep do_lock_umutex __umtx_op_wait_umutex amd64_syscall Xfast_syscall Looks like a thread is locked. In the log, there're may SyncSocket errors. For example: [20160710 13:12:53.238] SyncSocket[0x0000000827bf4480]: an error has occurred - code: 61, message: "Connection refused" ZFS has been enabled in my Freebsd installation. Around 40 folders have been shared. Quote Link to post Share on other sites
Helen Posted July 11, 2016 Report Share Posted July 11, 2016 that error is not critical for CPU. I'd rather take a look at the whole log, can you please send it to support? Also, make listing of your storage folder (the one where logs are) and see the size of .db files. Also please send it to support. Thanks! Quote Link to post Share on other sites
xiaoyu Posted July 30, 2016 Author Report Share Posted July 30, 2016 After talking to Helen in support ticket, I found that it was because there were too many peers of my public sharing folders. Sync is keeping "ping" the peers to check whether they're still online. If there're hundreds offline peers, my node is waiting the "ping" responses until timed out. That costs too many CPU. (state umtxn and uwait) So is it possible in future to add a parameter to disable active "ping" to other peers. I think that will free up the waiting locks. Quote Link to post Share on other sites
Helen Posted August 1, 2016 Report Share Posted August 1, 2016 well, as a few things to try: - clear peers' addresses cache (put peer_expiration date to zero), but that didn't help you, did it? - you can put either 2 or 4 in the second line on debug.txt file, to disable uTP or TCP connections respectively, but that may prevent some peers from connecting - them being public, one cannot know which protocol they will be able to establish connection on. Quote Link to post Share on other sites
Charles T Posted August 3, 2016 Report Share Posted August 3, 2016 I would like to report a similar issue with MacOS 10.12 PB3. I wonder if they are related in any way -- I have only 3 peers for my folders. For now I have resolved to quitting the app between sync attempts. Cheers. Quote Link to post Share on other sites
Helen Posted August 4, 2016 Report Share Posted August 4, 2016 no, it's not related. though the CPU problem on OS X is known for PB4, not PB3, and it's already addressed in Sync. Quote Link to post Share on other sites
Charles T Posted August 5, 2016 Report Share Posted August 5, 2016 Hi Helen, did you mean DP4? DP4 should be equivalent to PB3 -- and on Sync 2.3.8 the issue remains unresolved. Cheers. Quote Link to post Share on other sites
Helen Posted August 5, 2016 Report Share Posted August 5, 2016 No, I mean Beta4 - Mac OS X 10.12 (16A270f) to be more specific. and no, it's not fixed in 2.3.8, which was released on 22 June, while OS X beta3 and 4 - around a week ago Quote Link to post Share on other sites
Charles T Posted August 10, 2016 Report Share Posted August 10, 2016 Hi Helen, I can report the issue persists with the new PB4 (16A286a). Please kindly advise. Quote Link to post Share on other sites
Helen Posted August 10, 2016 Report Share Posted August 10, 2016 This is a known problem for PB4, and it's not yet fixed in v2.3.8. It will be fixed in future releases. Quote Link to post Share on other sites
Egregius Posted August 16, 2016 Report Share Posted August 16, 2016 I hope this is soon fixed. Issue still there with Siera PB5. Constant 100% CPU usage wich heatens the CPU and the fans blow faster. Therefore I need to stop btsync and only start it when needed. Quote Link to post Share on other sites
Helen Posted August 16, 2016 Report Share Posted August 16, 2016 @Charles T @Egregius I've PM'ed you both. Quote Link to post Share on other sites
Egregius Posted August 16, 2016 Report Share Posted August 16, 2016 Thank you for the fast response and update! As I'm a application engineer myself I tried both suplied versions and can confirm that on my mac OS Siera PB5 the cpu usage is back to normal. I'm now using Resilio Sync 2.4.0(640), I have the feeling that that version uses even less CPU than 2.3.9. The startup usage stops faster, also when idle cpu usage is less than 1%. So, I'm happy Quote Link to post Share on other sites
Helen Posted August 17, 2016 Report Share Posted August 17, 2016 16 hours ago, Egregius said: So, I'm happy So are we! Thank you : ) Quote Link to post Share on other sites
xiaoyu Posted September 19, 2016 Author Report Share Posted September 19, 2016 @Helen Looks like the issue has been fixed in 2.4.0. Now the CPU usage is always less than 20% even with more than 40 folders shared under FreeBSD. Thank you for all your great work! Quote Link to post Share on other sites
Helen Posted September 20, 2016 Report Share Posted September 20, 2016 Thank you for the repot and help in investigating it! Quote Link to post Share on other sites
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.