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: ↓ 2 Changed 15 years ago by andar
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: ↓ 4 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.
Raises in what sense? There is going to be a bit of overhead when limiting is employed since it needs to do more calculations.