Opened 13 years ago
Closed 9 years ago
#1490 closed bug (Fixed)
Daemon uses 4% cpu when idle
Reported by: | tes | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 1.3.7 |
Component: | Core | Version: | 1.3.5 |
Keywords: | Cc: | kenny@… |
Description
When running deluged, all torrents inactive and no interface connected, the daemon uses 4% cpu on my system (Atom N270).
I'm attaching deluged.profile. I've verified using netstat that no connections are open.
Change History (19)
comment:1 Changed 13 years ago by tes
comment:2 Changed 13 years ago by shql
- Version changed from 1.3.1 to other (please specify)
Same here, altough it's slighty lower (1%) on a pretty old machine.
~# strace -p 6137 Process 6137 attached - interrupt to quit select(12, [6 8 11], [], [], {0, 47996}) = 0 (Timeout) gettimeofday({1295799730, 323780}, NULL) = 0 gettimeofday({1295799730, 324190}, NULL) = 0 gettimeofday({1295799730, 324339}, NULL) = 0 gettimeofday({1295799730, 324610}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48612}) = 0 (Timeout) gettimeofday({1295799730, 373767}, NULL) = 0 gettimeofday({1295799730, 374121}, NULL) = 0 gettimeofday({1295799730, 374286}, NULL) = 0 gettimeofday({1295799730, 375011}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48227}) = 0 (Timeout) gettimeofday({1295799730, 423693}, NULL) = 0 gettimeofday({1295799730, 424057}, NULL) = 0 gettimeofday({1295799730, 424175}, NULL) = 0 gettimeofday({1295799730, 424420}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48771}) = 0 (Timeout) gettimeofday({1295799730, 473641}, NULL) = 0 gettimeofday({1295799730, 473956}, NULL) = 0 gettimeofday({1295799730, 474105}, NULL) = 0 gettimeofday({1295799730, 474433}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48789}) = 0 (Timeout) gettimeofday({1295799730, 523852}, NULL) = 0 gettimeofday({1295799730, 524167}, NULL) = 0 gettimeofday({1295799730, 524318}, NULL) = 0 gettimeofday({1295799730, 524565}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48659}) = 0 (Timeout) gettimeofday({1295799730, 573685}, NULL) = 0 gettimeofday({1295799730, 574033}, NULL) = 0 gettimeofday({1295799730, 574157}, NULL) = 0 gettimeofday({1295799730, 574557}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48640}) = 0 (Timeout) gettimeofday({1295799730, 623938}, NULL) = 0 gettimeofday({1295799730, 624354}, NULL) = 0 gettimeofday({1295799730, 624474}, NULL) = 0 gettimeofday({1295799730, 624732}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48461}) = 0 (Timeout) gettimeofday({1295799730, 673701}, NULL) = 0 gettimeofday({1295799730, 674073}, NULL) = 0 gettimeofday({1295799730, 674192}, NULL) = 0 gettimeofday({1295799730, 674636}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48556}) = 0 (Timeout) gettimeofday({1295799730, 723747}, NULL) = 0 gettimeofday({1295799730, 724103}, NULL) = 0 gettimeofday({1295799730, 724228}, NULL) = 0 gettimeofday({1295799730, 724483}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48715}) = 0 (Timeout) gettimeofday({1295799730, 773661}, NULL) = 0 gettimeofday({1295799730, 774017}, NULL) = 0 gettimeofday({1295799730, 774142}, NULL) = 0 gettimeofday({1295799730, 774541}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48657}) = 0 (Timeout) gettimeofday({1295799730, 823803}, NULL) = 0 gettimeofday({1295799730, 824119}, NULL) = 0 gettimeofday({1295799730, 824279}, NULL) = 0 gettimeofday({1295799730, 824535}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48698}) = 0 (Timeout) gettimeofday({1295799730, 873696}, NULL) = 0 gettimeofday({1295799730, 874009}, NULL) = 0 gettimeofday({1295799730, 874167}, NULL) = 0 gettimeofday({1295799730, 874567}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48664}) = 0 (Timeout) gettimeofday({1295799730, 923769}, NULL) = 0 gettimeofday({1295799730, 924120}, NULL) = 0 gettimeofday({1295799730, 924243}, NULL) = 0 gettimeofday({1295799730, 924495}, NULL) = 0 select(12, [6 8 11], [], [], {0, 48701}^C <unfinished ...> Process 6137 detached
comment:3 Changed 13 years ago by Cas
- Milestone changed from Future to 1.3.x
- Type changed from defect to bug
- Version changed from other (please specify) to 1.3.1
comment:4 Changed 13 years ago by tes
After noticing 100Mb per day network usage while not doing anything, I've investigated some more.
While idle, Deluge is still exchanging peers with other computers. I'm not sure if it is initiating these. It is at least responding to them (them = "get_peers"?). Disabling DHT and Peer Exchange does not solve the problem.
comment:5 follow-up: ↓ 8 Changed 12 years ago by Cas
What OS and libtorrent are you using?
How many torrents have you got loaded?
Libtorrent will still communicate with trackers even for torrents in paused state.
What plugins have you got enabled?
Have you encountered the same problem with 1.3.2?
comment:6 Changed 12 years ago by Cas
- Resolution set to invalid
- Status changed from new to closed
Closing due to no further information provided. Reopen if this still occurs with releases of latest libtorrent and deluge.
comment:7 Changed 12 years ago by tes
- Resolution invalid deleted
- Status changed from closed to reopened
- Version changed from 1.3.1 to 1.3.3
Reopening because this still happens, even after removing all torrents (in that case, restarting the daemon helps). Active plugins are label and webui.
comment:8 in reply to: ↑ 5 Changed 12 years ago by Cas
What OS and libtorrent are you using?
comment:9 Changed 12 years ago by tes
Arch Linux with libtorrent 0.15.9
comment:10 Changed 11 years ago by molari
- Milestone changed from 1.3.x to Future
- Status changed from reopened to pending
- Version changed from 1.3.3 to 1.3.5
libtorrent 0.16 deluge 1.35
on x86_64 (where gtod is not a syscall) deluged does about 30 ctxt switches per second while completly idle.
comment:11 Changed 11 years ago by HolgiH
This is caused by the use of Twisted for noblocking IO, since python doesn't have a working thread model and cannot afford to block for extended periods of time. It got worse with twisted >11.0.0 (which I'm currently using on Gentoo/x86); updating to 11.1.0 or later significantly raises the CPU use & context switch rate on an otherwise completely idle system, in line with the 4% observed here. Looking at http://labs.twistedmatrix.com/2011/11/twisted-1110-has-been-released.html I see: "The poll() reactor as default where applicable, instead of select() everywhere."
comment:12 Changed 11 years ago by molari
On Linux, PR_SET_TIMERSLACK via prctl might just do the trick?
comment:13 Changed 11 years ago by kruton
- Cc kenny@… added
comment:14 Changed 11 years ago by Cas
- Milestone changed from Future to performance
comment:15 Changed 11 years ago by AdmiralSausage
I love Deluge & was excited to get it running on my raspberry pi, but 5-8% CPU usage at idle is a no-go on a device which is pretty constrained at the best of times.
comment:16 Changed 11 years ago by AdmiralSausage
I shrink CPU usage to under 1% if I change the AlertManager?'s update interval from 0.05 (20 times a second) to 1 (once per second) in deluge/core/alertmanager.py. Are there any downsides to this?
It seems... odd... practice to have to poll for alerts (especially that frequently) but I don't know how the libtorrent API works so perhaps it's necessary.
In any case Twisted appears to be performing as advertised. It's not to blame just because it's being used to implement something approaching a tight loop.
comment:17 follow-up: ↓ 18 Changed 10 years ago by ezequielg
I can confirm that increasing the AlertManager?'s interval fixes this issue. I think that 0.05 is a too low value. Is it a problem to merge this upstream?
comment:18 in reply to: ↑ 17 Changed 10 years ago by holgerh
Replying to ezequielg:
I can confirm that increasing the AlertManager?'s interval fixes this issue. I think that 0.05 is a too low value. Is it a problem to merge this upstream?
I have been patching my Deluge on Gentoo to use 1s since forever without any problems (https://github.com/hhoffstaette/portage/blob/master/net-p2p/deluge/files/deluge-1.3.6-alertmanager_interval.patch). My guess is that this is by far the most common reason for excessive CPU usage.
comment:19 Changed 9 years ago by Cas
- Milestone changed from performance to 1.3.7
- Resolution set to Fixed
- Status changed from pending to closed
I have set it to 0.3s so that should reduce the idle cpu usage to a more reasonable level.
1.3-stable: [d6b44afb9981] develop: [19bc0fb46817]
Well, that didn't fit, so here it is: http://www.mediafire.com/?m3avpl58phylmmg