Deluge 1.3.3 CPU Usage Increase

[jbigs]

Hi,

I run a server often referred to as a 'seedbox', where we use Deluge for torrenting. The server has around 20 users on it, all running a seperate instance of deluged (and deluge-web).

Recently I upgraded the server from 1.3.1 to 1.3.3. Since then, there has been a noticeable dramatic CPU usage increase. ​http://i.imgur.com/cKhxp.png

As you can see, since I upgrade the average load has more than doubled! (Usually averages 5.00, now constantly 12+). Initially I thought it was probably just a lot of torrent hashchecking, but it has been 5 days now and still going strong.

The server itself has an Intel Xeon E5504 (quad core, 8 threads), 24 GB of RAM and a whopping 12 disks (so it shouldn't be IO wait causing it, nor is there a shortage of RAM ;-)).

Something in 1.3.3 has definitely caused much higher CPU usage.

I'm willing to do any testing necessary and provide anything I can. I don't want to have to roll back to 1.3.1 if I can avoid that!

Thanks in advance, jbigs

[jbigs]

I should probably mention, the server is running Ubuntu Server 10.04. It is definitely Deluge driving the load up, sorting htop by time, the first page of results is entirely deluged instances.

[andar]

Did you upgrade libtorrent at the same time? Do you know what version you had installed with deluge 1.3.1 and what version you have installed now?

There wasn't a lot of changes to deluged in the past couple of versions that would warrant such an increase in CPU usage.

[jbigs]

I upgraded using the PPA, so I would say so yes.

root@---:~# deluge --version deluge: 1.3.3 libtorrent: 0.14.10.0

I've just had a look at another server: (root@*)-(~) $ dpkg -s libtorrent-rasterbar5 | grep Version Version: 0.14.10-2~lucid~ppa1 (root@*)-(~) $ deluged --version 1.3.1

It looks like that version is newer... like I said I just use apt-get with the PPA so I haven't explicitly done anything. I'll have a play with updating to the latest libtorrent and see if that doesn't help.

[jbigs]

Sorry about the formatting above.

I just had a look at another server I had upgraded to 1.3.3 and it has a newer version:

root@%%%%:~# deluge --version deluge: 1.3.3 libtorrent: 0.15.6.0

This servers load shows the same spike as the graph I provided.

I'll try updating this same server to the latest libtorrent and see if it helps at all.

I don't have an explicit record of what the libtorrent version would have been prior to upgrade unfortunately.

If you would like shell access on one of these servers, I'm happy to set you up. Just require an email.

I'll upgrade to the latest libtorrent now and see if the graph starts to trend down at all!

[jbigs]

The deluge PPA still only has libtorrent 0.15.6.0, not the latest (0.15.7.0). I tried to upgrade manually but the apt-get version seems to have path precedence, and I can't remove it without deluge being removed at the same time.

If somebody wants to update the PPA I'm happy to test the new version. I have 2 servers both running 1.3.3 and exhibiting issues, with both 0.15.6.0 and 0.14.10.0, if there is an older version you'd like me to test with please let me know.

[andar]

You could try running deluged with a profiler to see if it's actually Deluge causing the CPU load rather than libtorrent.

You'll want to run the daemon process interactively and after you shut it down, it should print out a bunch of stats that you could attach to this ticket.

deluged -d --profile

[jbigs]

I rebooted one of the servers for some unrelated security updates and I cannot believe it... the load has returned to normal levels since. I was so shocked I had to reboot the other one... and it has done the same!

So I guess this is resolved. As a sysadmin and a programmer, I don't feel much closure!

I was thinking about it and I guess it wasn't necessarily deluge. I realise now I didn't kill any processes before the upgrade, so a lot of the instances were still 1.3.1 (and had a high CPU time just because they'd be running for weeks). I let apt-get upgrade a bunch of packages, so I guess any number of them could've been the cause (or none).

Thanks for your help andar. I will keep that command in mind for the future, but hopefully things will be smooth again now.