Your message dated Thu, 13 Aug 2009 10:57:13 -0400
with message-id <1250175433.12712.10.ca...@desktop>
and subject line azureus: Very high CPU load
has caused the Debian Bug report #466236,
regarding azureus: Very high CPU load
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
466236: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466236
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: azureus
Version: 3.0.4.2-1
Severity: important
The download directory of Azureus is, in my case, on a fat32 partition. When
a download begins, azureus spends a very long time (5 - 20 minutes)
"allocating" space in the download directory. The time required seems to go
up faster than linearly with the size of the file to be downloaded.
While azureus is allocating, the load average of the machine goes to
ridiculous levels (at least 10). Everything (mouse, keyboard, the onscreen
clock) freezes. Sometimes I cannot even go to a VC with control-alt-F2;
sometimes I can, but I have to wait for a while until the system reacts to
the keyboard command. There are no error messages. After the waiting period
is over, the download begins. The load average remains fairly high (1 or so)
and according to "top", java consumes about 25% CPU; this remains so until
the download is over.
I then discovered the option Tools -> Options -> Files -> "Enable
incremental file creation." With this, a download does not start with an
"allocating" phase. The download begins at once. At least, azureus says so;
but it is not true. By doing ls -al on the download directory I can see that
the complete file size is still being allocated in advance (with the same
effects as before: allocation proceeds very slowly, ridiculously high load
average, freeze of all processes including the download itself, which
remains at zero bytes until the allocation is finally finished).
This penomenon is fairly recent, but I could not say with which version of
azureus it started.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages azureus depends on:
pn java-gcj-compat | java-virtua <none> (no description available)
ii libcommons-cli-java 1.1-1 API for working with the command l
ii liblog4j1.2-java 1.2.15-2 Logging library for java
ii libseda-java 3.0-3 the Staged Event-Driven Architectu
ii libswt-gtk-3.3-java 3.3.1-3 Standard Widget Toolkit for GTK Ja
ii sun-java6-jre [java2-runtime] 6-04-2 Sun Java(TM) Runtime Environment (
azureus recommends no packages.
-- debconf-show failed
--- End Message ---
--- Begin Message ---
It was fixed around version 4 according to the changelog. It's now
4.2.0.4-1 in unstable.
--
Best regards,
Adrian Perez <[email protected]>
signature.asc
Description: This is a digitally signed message part
--- End Message ---
_______________________________________________
pkg-java-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/pkg-java-maintainers
