CPU 100% when rutorrent is downloading

QuickBox Support
#1

Hi all,

First, really thank you for this interface, this is VERY AWESOME !

But, I have an issue with rutorrent when I start a download, the CPU goes to 100% and all interface freeze a lot.

I have a good dedicated server :

  • Intel® Atom™ CPU C2750 @ 2.40GHz
  • Frequency: 2393.902
  • Secondary cache: 1024 KB ×8
  • [x8 core]
  • 16 GB RAM
  • 1To HDD
  • 2.5 Gbps internet
  • ubuntu 16.04 lts

For now, I have only one user : me !

I don’t understant why, but when I disable rtorrent service, everything is fine !

Can you help me please ?

Is this possible rutorrent / quickbox doesn’t understant I have 8 cores ?

Thank you by advance.

#2

Those ATOM processors sure do look good on paper, but they are a nightmare when it comes to processing even the smallest of loads. If I had to toss a guess… is this an Online.net server?

1 Like
#3

Hello @slimfaya,

How many torrents do you have in ruTorrent ?

Indeed when you look the CPU benchmark for the Intel® Atom™ CPU C2750 @ 2.40GHz, it has 3800 Average CPU Mark. This is not a lot if you run rTorrent, Plex, etc.

Speaking of this @JMSolo , maybe it would be interesting to have a minimum configuration to guarantee a good experience with QB? Even if it depends of everyone needs, it could be useful to know it before installing QB ? Just a thought :wink:

#4

@JMSolo I had a bonobox installed before, no problème with it, rutorrent worked fine.

@PastaGringo I made a test with only one torrent.
On my old server, I had a 1.8 Ghz CPU with plex and ruTorrent, no problem at all.

Benchmark compare my old CPU (rutorrent and plex OK) with my New CPU :

When I make a “top” command on linux, rutorrent consume only ~15 / 30 % of CPU when Quickbox and Rutorrent display 100%.

This is why I suppose only 1 or 2 cores are used with Quickbox.

Does Deluge consume as much as rutorrent ?

#5

This has everything to do with the processor. Not QuickBox. This is simply a matter of hardware.

This proves that point. I could fire up an ATOM via any provider and produce these same results.

Says where?

Deluge will (due to python processes) consume more than ruTorrent in that respect. It’s not so much a matter of application as it is hardware.

1 Like
#6

Thanks you two for your answers.

I understand what you said, but I can’t understand why on my old server rutorrent works perfectly and not on the new which is more powerfull.

I’m gonna to install quickbox on my old server to test.

#7

By the way, I can see RAM cache very high too (98% used).

Rutorrent works on my raspberry 3 without 100% CPU with Bonobox script.

I’m septic on the fact that my server is not powerful enough to run rutorrent, for me the problem comes from elsewhere.

To do some tests, can you explain how to remove and then install another version of rutorrent?

#8

I made some research, and I find this :

Can you say me if curl is linked with openssl instead of nss ?

#9

Have you looked at iotop to see what write speeds you’re seeing?

I’m wondering if what you’re seeing is due to the poor disk speeds on those atom boxes.

1 Like
#10

I make with my technician a smartmontools => no HDD error !
With iotop, writespeed is ~100mb/s, so no problem too because I limited download to 50mb/s just after and same result.

I see on this LINK that curl could generate the 100% CPU usage (many users say the same thing)

How can I install older version of curl to make some tests ?

(sorry for my bad english, i’m french :slight_smile: )

Thanks a lot !

#11

ldd /usr/bin/curl doesnt show nss libraries being used on mine. If you really want to be sure then compile it from source making sure to specify the openssl and disabling the nss but I’m not seeing it on mine.

I think you’re going down the wrong path on this. The messages you posted are about rtorrent just sitting there with the CPU at 100%. I assume you are actually able to download torrents, its just that the CPU is at 100%? I would really look at the disk io.

#12

It seems this error comes from CentOS, RedHat Linux and Fedora.
Did you install QB on one of these distributions ?

There is a “sanity check” to know if your curl is compilated with (outdated) NSS (instead of OpenSSL) :

curl -q --cipher RC4-SHA -s --include https://connection.s3.amazonaws.com/test

I tried on my server, the test passed without issue.

I also seach on QB lab, nowhere Curl is complilatd with specific version of NSS or OpenSSL.
It installed by apt-get so I guess it’s linked by default with the latest OpenSSL version.

You can check if curl has been compiled with OpenSSL or NSS with this command : curl --version
I can see GnuTLS which is another library to use SSL.

Anymay, you can test your disk with Bench and ./bench.sh -io :slight_smile:
Or with dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data

#13

Test Curl :

Test dd :

I think this is the HDD (certainly 5400 tr/min) the problem.

#14

yeah, I run that test on my raid0 SATA3 disks:

dd if=/dev/zero of=test.data bs=1M count=1000 conv=fdatasync;rm test.data
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.7026 s, 616 MB/s

#15

So Curl is OK :slight_smile:

I discovered this command (you may need to install the package lshw) to retrieve info about your disk: sudo lshw -class disk -class storage

Can we consider that your problem is “solved” ?

#16

Really thank you, yes this is solved, i’m going to flame my provider right now :slight_smile:

Very good comunity :wink:

2 Likes
#17

You’re welcome ! (N’hésite pas ;))

#18

I have the base model from online and experienced this issue. Was tempting to push my box to the one you have but if you’re experiencing the issue there too perhaps not. So the problem is the HDD?

#19

Yes, the problem is really my HDD, my provider propose to change because they know this is a problem.
This time, I choose 2x1TB HW RAID to be more powerfull and a xeon 3.6Ghz CPU.

1 Like