SchmitzKatze

[Solved] [V1.3.105] Higher Cpu Usage Than Older Versions On Linux/arm

Recommended Posts

I'm using BitTorrent Sync on Linaro Ubuntu running on a Cubietruck (ARM) for quite some time now. I noticed that BTSync uses considerably more CPU lately than it used to. Months ago, it was like 3%@idle. Right now, it's more like 13-20%@idle. Note: idle=devices are connected, but sync is finished

 

BTSync monitors about 9000 files (there used to be more files, like 15000) spread over 11 folders. I'm using the packages "btsync_1.3.1-1_all.deb" and "btsync-common_1.3.105-1_armhf.deb" installed from either ""http://ppa.launchpad.net/tuxpoldo/btsync/ubuntu" (which one is newer for apt).

 

The log is quite small (<20k) and mainly consists of "Incoming connection from xxx.xxx.xxx.xx:xxxx", like 200 lines.

 

Unfortunately, both PPAs do not provide older versions of BTSync, so I'm unable to downgrade. Is there anyone else experiencing the performance impact on Linux/ARM? What can I do to improve the situation?

Share this post


Link to post
Share on other sites

I'm having the same issue. It's using a lot more CPU on idle, and I'm running it on ubuntu intel 64 bit.

I've the same problem. Monitoring about 100k files though. Not sure if this is too much for btsync? Maybe it is and I need to look into other alternatives. 

Share this post


Link to post
Share on other sites

I don't think it's too much for it, because it worked just fine in the older versions. It's probably just a bug of some sort. If they don't get this fixed soon, I'm probably just going to download an older version and install it.

Share this post


Link to post
Share on other sites

Hi all,

 

We would like to reproduce the issue in our lab. Could you please share more information? Which "older" version consumed less CPU? 1.3.94? 1.3.50? 1.2.82?

Share this post


Link to post
Share on other sites

Ok, it seems my problem was that a peer was running 1.2.92

 

I don't have any debug log left from when the problem occurred but I recall it complained about being disconnected when trying to transfer a file.

Share this post


Link to post
Share on other sites

Unfortunately, I didn't check cpu load on regular basis, so it could be in for a while. Problem is, the repository does not contain any older version, so I can't go back and check when it happend. Is it possible to get older versions? What other information do you need? Btw, the high cpu use is also when no client is connected.

Share this post


Link to post
Share on other sites

Yeah, after I updated the peers to a newer client version, it still has a very high CPU usage. as in greater than 50% almost always. I also am unaware of what version this behavior started occurring.

Share this post


Link to post
Share on other sites

All,

Could you please try running official binary manually (not via PPA package) to seeif issue persists? We did not manage to reproduce CPU usage in idle mode in our lab.

Share this post


Link to post
Share on other sites

v1.2.67

Monitoring 9000 files - CPU is about 3-5%@idle. Calling the WebUI, CPU is about 9-11%. Monitoring 0 files, CPU is about 0.3%@idle.

 

v1.3.106

Monitoring 9000 files, CPU is about 10-12%@idle. Calling the WebUI, CPU is about 14-20%. Monitoring 0 files, CPU is about 0.3%@idle.

 

 

ATM, I don't have the time to check all versions in between. But it's clear that there has been a raise in CPU usage, at least on Linux/ARM. I'm using Lubuntu Server 14.04 (Linaros ARM version of Ubuntu Server, not to be confused with the Ubuntu Desktop LXDE) on a cubietruck.

 

Additionally, I think even with v1.2, CPU usage at idle should be improved. I have several services running like Apache, nginx, MySQL, Prosody, just to name a few, and they do not go above 0.1% CPU when doing nothing. I've read your suggestions from this thread, but it doesn't help in my case.

 

Note: @idle - sync is finished. It doesn't matter if there are any or 5 clients connected.

Share this post


Link to post
Share on other sites

@SchmitzKatze,

 

Could you please collect a debug log from 1.3.106 and send it to me to syncapp@bittorrent.com? Please mention this forum topic in the message body, note that log goes for RomanZ, and mark down the time when the "idle" state begins - I'll find out what BTSync consumes 10-12% of CPU for.

Share this post


Link to post
Share on other sites

We discussed CPU usage for the idling btsync process about 10 months ago in this thread:

 

http://forum.bittorrent.com/topic/21884-is-20-45-linux-nas-cpu-usage-too-high/

 

At that time, it had come down to 11-13% on my Linux NAS, which I gathered was accepted as normal. I've observed the same range of CPU usage since then. I also asked about this level of CPU usage at Synology's support forum here:

 

http://forum.synology.com/enu/viewtopic.php?f=19&t=71788

 

No one has ever responded, so for the past year I've accepted 13% CPU usage for the btsync process as non-harmful, or at least acceptable wear-and-tear. I've been using btsync as long as anyone, and I've never seen a 3% idling CPU usage when syncing my full complement of 23,000 files, but that would be nice.

Share this post


Link to post
Share on other sites

@JimmyTheSaint

 

Let's take a look what is BTSync doing to consume these 11-13% when idle. Can you please collect the debug log, send it to us together with the time mark when BTSync became idle?

 

It should not consume that much CPU to my understanding, so I'd to understand what is happening.

Share this post


Link to post
Share on other sites

@JimmyTheSaint

 

Let's take a look what is BTSync doing to consume these 11-13% when idle. Can you please collect the debug log, send it to us together with the time mark when BTSync became idle?

 

It should not consume that much CPU to my understanding, so I'd to understand what is happening.

OK, I sent the log. As I said, both of my NAS's have been idling at 13% for almost a year. All other processes idle at <0.4%.

Share this post


Link to post
Share on other sites

 

Just wanted to say that the problem seems fixed with version 1.4.xx. Thank you!

Au contraire. The problem was solved with 1.3.109 on my Linux NAS's (~7%CPU), but 1.4 sent the CPU back up to 25-30%. I haven't tested the latest 1.4 yet.

Share this post


Link to post
Share on other sites

No, it was not pure idle: there were other peers (including 1.3.109 peers) online at the time. But the Linux box would stay at 25-35% even between sync periods. I reported this in the first 1.4 feedback thread, but I haven't tried any of the 1.4 updates on the Linux box I updated. On my other Linux NAS (identical hardware and system), I've done a clean install of 1.4.75 and haven't yet added any sync directories. It's been idling at 0% CPU, no problem. It's in a remote location that won't allow me to access the webui, so I still have to wait several more days before I can go there and test it to see if it plays well with my 1.3.109 peers. If it's OK, I'll try doing a clean install of 1.4 on my main Linux NAS and see how it goes.

Share this post


Link to post
Share on other sites

V1.4.75 on all clients. CPU usage on Cubietruck (ARM/Linux) is around 14% when someone connects to the WebUI. After Connections to WebUI are closed, CPU is 1% at max.

@JimmyTheSaint

What I'd try with your sync-peers-free Synology: add some directories with several thousand files. After indexing finished, quit every connection to WebUI and restart btsync. During restart check the cpu usage to estimate when btsync is up and running again. From my experience, the cpu use at this point should be fairly low. Now connect to the WebUI, cpu shoulde be higher now. Then quit connection to the WebUI and check if the cpu calms down. 1.3.105 didn't calm down, while 1.4.75 does.

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.