Opened 13 years ago

Closed 11 years ago

Last modified 7 years ago

#1606 closed bug (Fixed)

[win32] High CPU usage with low activity

Reported by: adagui Owned by:
Priority: major Milestone: 2.x
Component: GTK UI Version: 1.3.1
Keywords: Cc:

Description (last modified by Cas)

Latest version (1.3.1) in Windows Server 2008 R2.

Only 400 torrents loaded. 2 are active (download 0KB/s, upload 50KB/s)

Deluge uses 53% CPU!!! (for comparison, utorrent only uses 1-2% cpu under this usage)

Running Deluge in classic mode.

System: 100mbit connection Core 2 Duo 4GB RAM

Attachments (1)

deluge_high_cpu.png (57.8 KB) - added by adagui 13 years ago.
High CPU with low activity

Download all attachments as: .zip

Change History (13)

Changed 13 years ago by adagui

High CPU with low activity

comment:1 Changed 13 years ago by shnurapet

I have ~20 torrents seeding (with ~130 paused tasks in list) in Fedora 14 x86_64, and the GUI is taking 100% CPU. Low when it starts. Seen it for two months now.

AMD Athlon64 X2 4200+ 2GB RAM

git master build plugins: Notifications, WebUI, BlackList?

comment:2 Changed 13 years ago by Cas

  • Description modified (diff)

comment:3 Changed 13 years ago by Cas

  • Component changed from core to gtkui
  • Milestone changed from Future to 1.3.x
  • Summary changed from High CPU usage with low activity to [win32] High CPU usage with low activity
  • Type changed from defect to bug

comment:4 Changed 11 years ago by gazpachoking

The speed optimizations in #2184 should help this problem.

comment:5 Changed 11 years ago by miskoala

I have this problem with high cpu usage when deluge-gtk clients are connected. I'm running daemon, 1.3-stable git on Archlinux, Intel Atom N2800 @ 1.86GHz, 4GB RAM. 200 torrents started (seeding), 300 paused.

uname -a
Linux server 3.6.6-1-ck #1 SMP PREEMPT Mon Nov 5 14:59:40 EST 2012 x86_64 GNU/Linux
no clients connected (5-11% CPU usage)
PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM     TIME+ COMMAND           
29026 deluge     1   0  625m 278m 8312 S   9,6  7,1   4:53.17 deluged           

1 client connected with deluge-gtk (50-70% CPU usage):
PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM     TIME+ COMMAND           
26772 deluge     6   0  625m 280m 8340 S  57,0  7,1  15:45.62 deluged

2 clients connected with deluge-gtk:
PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM     TIME+ COMMAND           
26772 deluge     6   0  625m 280m 8340 R 102,6  7,1  13:15.93 deluged           

This speed optimizations in #2184 didn't help with cpu usage

comment:6 Changed 11 years ago by Cas

@miskoala That's because the fix is for GTK UI not daemon cpu usage.

comment:7 Changed 11 years ago by miskoala

ok


and some more results for daemon cpu usage on my machine;

50-70% when all torrents (500) are paused and there is 1 client connected (gtk or web) 8% when all torrents (500) are paused and there is no client connected 3% when there is 0 torrents on list and 1 client connected 2,5% when there is 0 torrents on list and no client connected

comment:8 Changed 11 years ago by miskoala

sorry there is problem with enter, please delete above message :P

some more results for daemon cpu usage on my machine;

50-70% when all torrents (500) are paused and there is 1 client connected (gtk or web)
8% when all torrents (500) are paused and there is no client connected
3% when there is 0 torrents on list and 1 client connected
2,5% when there is 0 torrents on list and no client connected

comment:9 Changed 11 years ago by miskoala

I forgot to mention I used libtorrent 0.16.x

With libtorrent 0.15.10 cpu usage for daemon is lower when there is 1 client connected: 25-45% (500 torrents on list)

comment:10 Changed 11 years ago by Cas

  • Milestone changed from 1.3.x to performance

comment:11 Changed 11 years ago by bro

  • Milestone changed from performance to 1.4.0
  • Resolution set to fixed
  • Status changed from new to closed

This has been fixed in develop branch (to be v1.4)

Most important improvements:

comment:12 Changed 7 years ago by Cas

  • Milestone changed from 2.0.x to 2.x

Milestone renamed

Note: See TracTickets for help on using tickets.