Your message dated Mon, 18 Feb 2008 10:21:27 -0800
with message-id <[EMAIL PROTECTED]>
has caused the $gProject $gBug report #$ref,
regarding azureus: Very high CPU load
to be marked as having been forwarded to the upstream software
author(s) "Azureus Team" <[EMAIL PROTECTED]>
(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 ---
The following bug report indicates that preallocating the full size of
the file to be downloaded on a FAT32 partition while running Azureus
on Linux results in very high CPU usage. He also indicates that
clearing the option Tools -> Options -> Files -> "Enable incremental
file creation." does not help.
Cheers,
Shaun
On Feb 17, 2008 3:15 AM, Jan Willem Stumpel <[EMAIL PROTECTED]> wrote:
> 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 ---
