top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers Swap: 1020116k total, 940k used, 1019176k free, 405756k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij
213mb memory and 50% CPU seems a bit excessive.
azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
Anyone else seeing this?
Garry
Garry Harthill writes:
top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers Swap: 1020116k total, 940k used, 1019176k free, 405756k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij
213mb memory and 50% CPU seems a bit excessive.
azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
Anyone else seeing this?
When you start azureus, use 'gij -verbose:class'. See if any of the classes are loaded 'bytecode'.
Andrew.
Hi
On Tue, 28 Feb 2006 14:41:57 +0000, Andrew Haley wrote:
Anyone else seeing this?
When you start azureus, use 'gij -verbose:class'. See if any of the classes are loaded 'bytecode'.
2929 unique classes. I'm impressed. Some of these are bytecode, indeed. Complete list is attached.
On Tue, 2006-02-28 at 16:22 +0100, Ralf Ertzinger wrote:
Hi
On Tue, 28 Feb 2006 14:41:57 +0000, Andrew Haley wrote:
Anyone else seeing this?
When you start azureus, use 'gij -verbose:class'. See if any of the classes are loaded 'bytecode'.
2929 unique classes. I'm impressed. Some of these are bytecode, indeed. Complete list is attached.
Thanks. I see we're using a slow interpreter for the crypto code. This is a bad idea. I've filed two bugs...
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183451 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183452
AG
Andrew Haley writes:
Garry Harthill writes:
top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers Swap: 1020116k total, 940k used, 1019176k free, 405756k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij
213mb memory and 50% CPU seems a bit excessive.
azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
Anyone else seeing this?
When you start azureus, use 'gij -verbose:class'. See if any of the classes are loaded 'bytecode'.
It looks like this guess was wrong. The fact that others are seeing degraded functionality as well as degraded performancew suggests that something major is wrong.
Andrew.
On Tuesday, 28 February 2006 at 15:30, Garry Harthill wrote:
top - 14:24:28 up 5 days, 3:41, 5 users, load average: 3.78, 3.61, 3.27 Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie Cpu(s): 57.0% us, 10.3% sy, 0.0% ni, 31.1% id, 1.3% wa, 0.3% hi, 0.0% si Mem: 1027288k total, 1002144k used, 25144k free, 39564k buffers Swap: 1020116k total, 940k used, 1019176k free, 405756k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13132 garry 15 0 966m 213m 37m S 50.6 21.3 227:27.00 gij
213mb memory and 50% CPU seems a bit excessive.
azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
Anyone else seeing this?
What I'm seeing is deficient functionality. FE version seems to be able to handle only one download at a time and at far lower speed, i.e. only one of all active downloads actually shows any "Down speed", all others are at zero. It is also much slower in connecting to tracker and finding out how many peers and seeds there are. The binary from azureus.sf.net coupled with jpackage.org's sun java rpm works flawlessly and handles as many concurrent downloads as I want.
Regards, R.
On Tue, 2006-02-28 at 18:43 +0100, Dominik 'Rathann' Mierzejewski wrote:
What I'm seeing is deficient functionality. FE version seems to be able to handle only one download at a time and at far lower speed, i.e. only one of all active downloads actually shows any "Down speed", all others are at zero.
I'm not seeing this, but please file a bug report and we can try to solve it.
Thanks,
AG
On Tue, 2006-02-28 at 14:30 +0000, Garry Harthill wrote:
213mb memory and 50% CPU seems a bit excessive.
azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
Anyone else seeing this?
It's big for me, but not using so much CPU. Please file a bug report @ http://bugzilla.redhat.com.
Thanks,
AG
On 01/03/06, Anthony Green green@redhat.com wrote:
On Tue, 2006-02-28 at 14:30 +0000, Garry Harthill wrote:
213mb memory and 50% CPU seems a bit excessive.
azureus-2.4.0.0-0.20060209cvs_1.fc5 glib-java-0.2.3-1.2 cairo-java-1.0.2-0.2 libgconf-java-2.12.1-2.2 libgtk-java-2.8.3-1.2 java-1.4.2-gcj-compat-1.4.2.0-40jpp_80rh
Anyone else seeing this?
It's big for me, but not using so much CPU. Please file a bug report @ http://bugzilla.redhat.com.
CPU usage varies. This was maybe a particularly high example. Anyway, bugged: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183461
On Tue, 28 Feb 2006 14:30:35 +0000, "Garry Harthill" gazzerh@gmail.com wrote:
213mb memory and 50% CPU seems a bit excessive.
Anyone else seeing this?
Nope, mine is at about 53MB with Fedora torrents. It eats a bit of CPU, but I run a VIA C3. Heck, ssh eats CPU on that wimpy chip.
-- Pete
Pete Zaitcev writes:
On Tue, 28 Feb 2006 14:30:35 +0000, "Garry Harthill" gazzerh@gmail.com wrote:
213mb memory and 50% CPU seems a bit excessive.
Anyone else seeing this?
Nope, mine is at about 53MB with Fedora torrents. It eats a bit of CPU, but I run a VIA C3. Heck, ssh eats CPU on that wimpy chip.
OH, right. Thanks for that. I wonder what causes the difference.
Andrew.
devel@lists.stg.fedoraproject.org
-
Andrew Haley -
Anthony Green -
Dominik 'Rathann' Mierzejewski -
Garry Harthill -
Pete Zaitcev -
Ralf Ertzinger