Opened 15 years ago
Closed 14 years ago
#935 closed bug
High cpu usage with dowload speed limit
Reported by: | wWolfovich@gmail.com | Owned by: | andar |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | GTK UI | Version: | 1.3.0 |
Keywords: | Cc: | supersur@gmail.com |
Description
Cpu usage raises when I limit download speed of any torrent or general dl speed.
Change History (30)
follow-up: 2 comment:1 by , 15 years ago
comment:2 by , 15 years ago
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.
follow-up: 4 comment:3 by , 15 years ago
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 by , 15 years ago
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 by , 15 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Please try using a more recent version of libtorrent and boost.
comment:6 by , 15 years ago
Milestone: | → 1.2.0 |
---|---|
Resolution: | worksforme |
Status: | closed → reopened |
Version: | 1.1.7 → 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 by , 15 years ago
Cc: | added |
---|---|
Version: | 1.2.0_rc5 → 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 by , 15 years ago
Status: | reopened → pending |
---|
Can you try this with libtorrent 0.15 and see if the problem persists?
comment:9 by , 14 years ago
Milestone: | 1.3.0 |
---|---|
Version: | 1.2.0 → 1.2.3 |
I am using libtorrent 0.15 and can confirm that the problem persists.
comment:10 by , 14 years ago
Milestone: | → 1.3.0 |
---|
sahilm can you give a bit more details as to your setup and the exact issue.
comment:11 by , 14 years ago
Component: | other → libtorrent |
---|
comment:12 by , 14 years ago
Milestone: | 1.3.0 |
---|
comment:13 by , 14 years ago
Status: | pending → 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 by , 14 years ago
Status: | closed → reopened |
---|---|
Version: | 1.2.3 → 1.3.0 |
same bug in Core Version: 1.3.0 (libtorrent version: 0.15.4.0)
comment:15 by , 14 years ago
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 by , 14 years ago
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:18 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
Component: | libtorrent → 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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
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 by , 14 years ago
Eh, scratch that the usage doesn't climb. The usage has climbed to 100% but only after running for around 4 days.
comment:25 by , 14 years ago
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 by , 14 years ago
Component: | gtkui → core |
---|
comment:27 by , 14 years ago
Component: | core → 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 by , 14 years ago
Status: | reopened → 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 by , 14 years ago
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 by , 14 years ago
Status: | pending → 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.
Raises in what sense? There is going to be a bit of overhead when limiting is employed since it needs to do more calculations.