[Solved] 100% CPU load on FreeBSD

[xiaoyu]

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.

[Helen]

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! 

[xiaoyu]

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.

[Helen]

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. 

[Charles T]

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.

[Helen]

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. 

[Charles T]

Hi Helen, did you mean DP4? DP4 should be equivalent to PB3 -- and on Sync 2.3.8 the issue remains unresolved. Cheers.

[Helen]

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

[Charles T]

Hi Helen, I can report the issue persists with the new PB4 (16A286a). Please kindly advise.

[Helen]

This is a known problem for PB4, and it's not yet fixed in v2.3.8. It will be fixed in future releases. 

[Egregius]

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.

[Helen]

@Charles T @Egregius

I've PM'ed you both. 

[Egregius]

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 

[Helen]

16 hours ago, Egregius said:

So, I'm happy

So are we! Thank you : )

[xiaoyu]

@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!

[Helen]

Thank you for the repot and help in investigating it!