| Summary: | uses 95% of my cpu | ||
|---|---|---|---|
| Product: | [Applications] kget | Reporter: | Helge Hielscher <hhielscher> |
| Component: | general | Assignee: | KGet authors <kget> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | berry, bss, bugs.kde.org, damir.perisa, rasasi78, webmaster, wilbert |
| Priority: | NOR | ||
| Version: | 0.8.1 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
cjb
2002-12-16 08:48:58 UTC
What's your kget version? What output do you get of `ps aux | grep kget' when it's using so much CPU? darkmoon@pch $ ps aux | grep kget pch 28691 87.6 2.6 72908 16876 ? R 16:40 48:08 kget -caption KGet -icon kget -miniicon kget pch 29019 0.0 0.0 1388 476 pts/0 S 17:35 0:00 grep kget I attach the debugger and i get 3 thread sleeping on slave:run() warker.wait() this 3 must not take more that any cpu time ( i was downloading 3 files so this are my slave threads) 1 thread is the thread manager running on pool() in libc.so.6 the last (the only running) on kapp.exec() and is this that is taking 99% of cpu... I have the same problems under v 8.3 ,SUSE 8.1 Takes up all free cpu when downloading 1 file (ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo/releases/1.4_rc2/x86/i686/livecd/gentoo-grp-i686-1.4_rc2.iso) Phil I have the same problem, i saved an .m3u from mp3.com, containing about 140 urls. kget took a *long* time to queue up these files, then it finally did, and is now using 50% of the CPU, with X using the other 50%. KGet also has 40M in the RSS part of top(the programs memory usage) and 54M in share(memory+libs). it either suggests kget uses a *large* ammount of memory for each item in the queue, or something. As soon as i closed kget X stopped cpu. Here is current version information Package: kget Version: 4:3.1.0-0woody2 -- System Information Debian Release: 3.0 Kernel Version: Linux tiger 2.5.59 #1 Wed Feb 12 11:25:37 PST 2003 i686 unknown Versions of the packages kget depends on: ii kdelibs4 3.1.0-0woody5 KDE core libraries ii libart-2.0-2 2.3.8-1 The Gnome 2 canvas widget - runtime files. ii libc6 2.2.5-11.2 GNU C Library: Shared libraries and Timezone ii libfam0 2.6.6.1-5.2 client library to control the FAM daemon ii libjpeg62 6b-5 The Independent JPEG Group's JPEG runtime li ii libpng3 1.2.1-1.1.wood PNG library - runtime ii libqt3-mt 3.1.1+cvs.2002 Qt GUI Library (Threaded runtime version) ii libstdc++2.10- 2.95.4-11woody The GNU stdc++ library ii xlibs 4.1.0-16 X Window System client libraries ii zlib1g 1.1.4-1 compression library - runtime Subject: Re: uses 95% of my cpu
On Saturday 15 February 2003 23:37, you wrote:
> ------- I have the same problem, i saved an .m3u from mp3.com, containing
> about 140 urls. kget took a *long* time to queue up these files, then it
> finally did, and is now using 50% of the CPU, with X using the other 50%.
> KGet also has 40M in the RSS part of top(the programs memory usage) and 54M
> in share(memory+libs). it either suggests kget uses a *large* ammount of
> memory for each item in the queue, or something. As soon as i closed kget
> X stopped cpu.
I think this is a different problem -- having 140 threads running and 140
download windows, timers and various other widgets is surely using some RAM
and CPU (kget currently creates all those things even if it does not show any
dialog for a download, so there is quite some room for optimization).
Cheers
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----
iQEVAwUBPmND5KWgYMJuwmZtAQHnsAgAszA2+GP2ydgF21Pjr3C7GDbg/gFGpLB3
Ji2mhJtYf6CWXc3tel2ct3CGuTCUYvBtJeLyon2p7JSGfMnXwpu6xvcxhhm6VMlL
cn1IEsV1zwKiVsMz/9Qnm+z+eNcwlepY/WGH4VEr8h4/Yh1ryZdRl38efrR9CRgD
F14SXkIJh46kGjCPWMXasGtogUkPKDTt1xJYaLeVvadmmEKX24CAQ3s/Srz8GbbZ
Qe9lAa6wugh68fyxr4hk/DkEZBJFhmsSxQpyF6X2hMkC0DXd93IVarNd11vca4q+
ID84hL5NOnQEUBOzZHoXkAd+ERjHq4cHrZnL0dNMwGmox5RChq4CZQ==
=cJqR
-----END PGP SIGNATURE-----
this problem still exists as of latest cvs (10/25/2003) i didn't have the kget window open and would have totally missed it were it not for the fact that my athlon xp 2000+ temp was at 71C (?) then i checked cpu usage and there was kget right at the top (pun intended) I saved a webpage on my h/d, konqi started kget and kget sat in the kicker panel after that. It started using 50% of the CPU, not doing anything. The download was complete, and the page was saved. It also used 18% of mem., which is lots. It had consumed around 57:46.59m of time (reported from top), which is just not acceptable. I didn't experience this with <= 3.1.4, just seems to happen with the 3.2beta1. i am >still< having this problem in kde-3.2.1 compiled from source on a fedora core 1 system. i am the original poster of this bug (my email has changed since then (a year ago). to reiterate, sometimes (not everytime), when i download something using kget (via konqeror), it monopolizes my cpu and doesn't give it up even after the download has completed. In kde-3.2.2, compiled from source, it consumes too much CPU, and too much memory, up to 200M when it downloads a large file, for example, an iso image. And it only has one file in the queue. The problem is also that this huge amount of memory is never released, until I kill kget. Regards. Replaced cjb@cs.utexas.edu with hhielscher@unternehmen.com due to bounces by reporter I can confirm this behavior with both SuSE 9.2, KDE 3.4 and Kubuntu 5.04, KDE 3.4.1. At this moment KGet is using ~96% CPU, with 2 active downloads and 5 queued. Sometimes it almost seems as if KGet takes up more CPU when the downloads come through slowly (~2Kbps) than at a normal rate (~50Kbps.) Memory usage is moderate. Is KGet still actively maintained? *** This bug has been confirmed by popular vote. *** *** Bug 57251 has been marked as a duplicate of this bug. *** *** Bug 58726 has been marked as a duplicate of this bug. *** *** Bug 63460 has been marked as a duplicate of this bug. *** *** Bug 88822 has been marked as a duplicate of this bug. *** top says (SVN 3.5 branch) PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 32646 kdesvn 25 0 113m 23m 15m R 99.0 4.7 29:58.78 kget This still happens with version 0.8.5 which is part of KDE 3.5.0. I have just downloaded the Windows version of OpenOffice, during which time KGet was consuming 99% of my CPU - despite having closed its window. Now the download has complete, it is still using 99% of my cpu to do nothing... ---- top - 12:29:10 up 1:19, 3 users, load average: 1.12, 1.25, 0.93 Tasks: 134 total, 3 running, 131 sleeping, 0 stopped, 0 zombie Cpu(s): 48.6% us, 11.7% sy, 0.0% ni, 39.3% id, 0.0% wa, 0.0% hi, 0.3% si Mem: 515000k total, 508368k used, 6632k free, 26892k buffers Swap: 546200k total, 164k used, 546036k free, 144332k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 6897 james 25 0 28460 16m 12m R 97.4 3.3 12:02.47 kget ---- After closing it and relaunching, kget behaves itself, as this output from PS shows... james 11689 4.3 2.6 25420 13896 pts/2 S 12:31 0:00 kget I am on KDE 3.5.4 with KGet 0.8.5 on Linux 2.4.33 and am also experiencing this bug. I don't know what triggers this behavior but strace shows that KGet is constantly looping on select:
select(20, [3 5 6 7 9 13 18 19], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1157249144, 176307}, NULL) = 0
gettimeofday({1157249144, 176419}, NULL) = 0
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1157249144, 177478}, NULL) = 0
select(20, [3 5 6 7 9 13 18 19], [], [], {0, 0}) = 0 (Timeout)
gettimeofday({1157249144, 177746}, NULL) = 0
gettimeofday({1157249144, 177919}, NULL) = 0
ioctl(5, FIONREAD, [0]) = 0
gettimeofday({1157249144, 178054}, NULL) = 0
select(20, [3 5 6 7 9 13 18 19], [], [], {0, 0}) = 0 (Timeout)
This is unreasonable behavior and is probably a result of the timeout passed to select not being reset somewhere.
I can confirm this bug on KDE 3.5.5. i have the same problem on kde 3.5.5 with opensuse rpm *** Bug 139016 has been marked as a duplicate of this bug. *** *** Bug 117793 has been marked as a duplicate of this bug. *** Due to the move from the make_kget_cool branch back into kdenetwork, this issue has been resolved. For more details about the new KGet please have a look at this page (1st article): http://commit-digest.org/issues/2007-02-25/ |