Opened 15 years ago

Closed 13 years ago

#935 closed bug

High cpu usage with dowload speed limit

Reported by: wWolfovich@… Owned by: andar
Priority: major Milestone:
Component: GTK UI Version: 1.3.0
Keywords: Cc: supersur@…

Description

Cpu usage raises when I limit download speed of any torrent or general dl speed.

Change History (30)

comment:1 follow-up: Changed 15 years ago by andar

Raises in what sense? There is going to be a bit of overhead when limiting is employed since it needs to do more calculations.

comment:2 in reply to: ↑ 1 Changed 15 years ago by wWolfovich@…

Replying to andar:

Raises in what sense? There is going to be a bit of overhead when limiting is employed since it needs to do more calculations.

It raises from about 0% to ~60% of my double core AMD_Athlon64_X2_5600+ CPU usage.

comment:3 follow-up: Changed 15 years ago by anonymous

It's up to 80% (strangely, it's system time, not user time). Core 2 Duo, T7500, Debian 5.0, Deluge 0.5.9.3, Boost 1.34.1

comment:4 in reply to: ↑ 3 Changed 15 years ago by wWolfovich@…

Replying to anonymous:

It's up to 80% (strangely, it's system time, not user time). Core 2 Duo, T7500, Debian 5.0, Deluge 0.5.9.3, Boost 1.34.1

Man, try more recent version, it is already 1.1.9, or even svn. But realy i tried, and it's still there.

comment:5 Changed 14 years ago by andar

  • Resolution set to worksforme
  • Status changed from new to closed

Please try using a more recent version of libtorrent and boost.

comment:6 Changed 14 years ago by wWolf

  • Milestone set to 1.2.0
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 1.1.7 to 1.2.0_rc5

Cofirm that it's still there, and that it eats 100% of one of cores of my dual core CPU by "system" load. In addition I noticed that if I start download with a limited speed there's no unusual overhead, but if I then set unlimited speed for that download and after some time when it reaches maximum, and I set a half from that maximum, then in 2-5 minutes it begins to load one of the cores to maximum.

comment:7 Changed 14 years ago by seron

  • Cc supersur@… added
  • Version changed from 1.2.0_rc5 to 1.2.0

I noticed that if "Per Torrent" "Maximum Connections" and "Maximum Upload Slots" are limited (in my case to 100/2) CPU utilization hardly ever peaks and simmers at a few %. One of the parameter settings may suffice.

This is on a Pentium M 1.4 GHz CPU system with Gentoo Linux, deluge 1.2.0, libtorrent 0.14.8-r2, boost 1.35.0-r5.

comment:8 Changed 14 years ago by andar

  • Status changed from reopened to pending

Can you try this with libtorrent 0.15 and see if the problem persists?

comment:9 Changed 14 years ago by sahilm

  • Milestone 1.3.0 deleted
  • Version changed from 1.2.0 to 1.2.3

I am using libtorrent 0.15 and can confirm that the problem persists.

comment:10 Changed 14 years ago by Cas

  • Milestone set to 1.3.0

sahilm can you give a bit more details as to your setup and the exact issue.

comment:11 Changed 14 years ago by andar

  • Component changed from other to libtorrent

comment:12 Changed 14 years ago by Cas

  • Milestone 1.3.0 deleted

comment:13 Changed 14 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

comment:14 Changed 13 years ago by istp

  • Status changed from closed to reopened
  • Version changed from 1.2.3 to 1.3.0

same bug in Core Version: 1.3.0 (libtorrent version: 0.15.4.0)

comment:15 Changed 13 years ago by wickedboy

confirmed this is occuring on 1.30 libtorrent 0.15.1 on a gentoo 64 bit install.. the cpu usage jumps to 100% of one core after the speed throttling changes (opens up at non-peak period on account and closes during peak)...

comment:16 Changed 13 years ago by wickedboy

upgraded to libtorrent 0.15.4 and recompiled ... there is a slight improvement (now using around 50% of one core instead of 100%).. however, this has only been running for about 20 hours, so will need to run for a bit longer.. also number of torrents has halved from 4 to 2

comment:17 Changed 13 years ago by wickedboy

now sitting up at 67% same number of torrents.

comment:18 Changed 13 years ago by wickedboy

now at 100% of one core after 2 days of running.. this is actually pushing the speed of that core up to it's maximum 3GHz (and hence raising the carbon footprint)..

comment:19 in reply to: ↑ description Changed 13 years ago by robertseaton

Confirmed on Ubuntu 10.10. CPU usage ramps up over time, capping at 100%.

Core Version: 1.3.0 libtorrent version: 0.15.4.0

comment:20 Changed 13 years ago by damoxc

  • Component changed from libtorrent to gtkui

This appears to be an issue with the gtk client, not with libtorrent or the Deluge daemon.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                               
28635 damien    20   0  731m  43m 8132 R  100  2.2   5451:36 /usr/bin/deluge  
28652 damien    20   0  383m  43m 3320 S    1  2.1  49:35.59 deluged                                               

This also appears to be roughly a 40%user / 60% system split.

Cpu2  : 39.9%us, 60.1%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

comment:21 Changed 13 years ago by damoxc

So of course the obvious work around to the high cpu-usage is to disable classic mode and only have the gtk client open when required and deluged will not be using the same amount of cpu whilst actually downloading, consequently reducing your carbon footprint :-)

comment:22 Changed 13 years ago by wickedboy

Hi

I'm not using the gtk client.. I'm using the web client and this is from remote machines (e.g. laptops on the same LAN). So this does not match my experience.

I am not running X windows on the box that is running deluge.

cheers Allan

comment:23 Changed 13 years ago by bleak

I'm having this problem on Ubuntu 10.10, I am running Deluge 1.3.900-dev libtorrent is 0.15.4.0

I thought it was this bug report that mentioned it, but somewhere I read that it had been fixed in the development version, hence I'm running that.

Strangely, running it without classic mode I don't have this problem, even if I leave the gtk client open all the time.

comment:24 Changed 13 years ago by bleak

Eh, scratch that the usage doesn't climb. The usage has climbed to 100% but only after running for around 4 days.

comment:25 Changed 13 years ago by wickedboy

I'll confirm exactly the same behaviour (about 4 days to reach 100% cpu).. I am not running in classic mode, I am not even using the gtk client... I am using the web client on a remote machine hence why it is running 100% of the time............. BTW devs, even if this was a problem only in classic mode or only with the GTK client, this still constitutes as a bug :)

comment:26 Changed 13 years ago by wickedboy

  • Component changed from gtkui to core

comment:27 Changed 13 years ago by damoxc

  • Component changed from core to gtkui

This is an issue with the gtk ui, there is a separate (and now fixed) issue for the web ui (#1312).

I experienced this bug myself so can 100% say this is not deluged.

comment:28 Changed 13 years ago by Cas

  • Status changed from reopened to pending

There is a ticket that links the high cpu usage to opening an external application (Open Folder context menu item): #1396

Please verify that this bug is caused by download speed limit set and not the above issue.

I am changing this to pending as this is turning into generic high cpu usage ticket for completely different issues.

comment:29 Changed 13 years ago by socker

My problems are the same as in #1396, download limit has never caused high cpu load for me. Confirmed on two computers using the same setup: Arch Linux, deluge 1.3.1-1, libtorrent-rasterbar 0.15.4-2.

comment:30 Changed 13 years ago by trac-robot

  • Status changed from pending to closed

This ticket was closed automatically by the system. It was previously set to a Pending status and hasn't been updated within 14 days.

Note: See TracTickets for help on using tickets.