Bug 199882 - Running for days causes large Memory and CPU usage [gcj]
Summary: Running for days causes large Memory and CPU usage [gcj]
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: azureus
Version: 5
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Anthony Green
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-07-23 22:06 UTC by David Timms
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-11 21:29:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Timms 2006-07-23 22:06:10 UTC
Description of problem:
If azureus is running for say 48 hours, it tends to consume all available CPU
and memory, making the machine really slow.

Version-Release number of selected component (if applicable):
azureus-2.4.0.3-0.20060529cvs_1.fc5
libgcj-4.1.1-1.fc5
Java 1.4.2
 Free Software Foundation, Inc.
SWT v3139, gtk
Linux v2.6.17-1.2159_FC5, i386

How reproducible:
Has done it a few times whenever, it has been running for a long time (days).
(over the past few months).

Steps to Reproduce:
1. azureus
2. download some torrents
3. 3 active torrent downloads, [currently none downloading]
   10 available torrents, [currently none downloading]
4. leave it going for a long time > 48 hours
  
Actual results:
Machine very unresponsive. Using lots of swap and ram and cpu.
Azureus itself takes a long time to respond to mouse clicks eg the About and
copy of the version info.

top - 08:02:50 up 22:27,  3 users,  load average: 5.98, 5.75, 5.34
Tasks: 112 total,   2 running, 109 sleeping,   0 stopped,   1 zombie
Cpu(s): 94.0% us,  3.0% sy,  0.0% ni,  0.0% id,  2.7% wa,  0.3% hi,  0.0% si, 
0Mem:    515644k total,   508992k used,     6652k free,     2152k buffers
Swap:  1859808k total,   148264k used,  1711544k free,    88200k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2585 davidt    15   0 1165m 309m  24m S 84.9 61.4 584:09.39 gij
 2347 root      15   0  179m  20m 5488 S  9.7  4.1  43:41.30 Xorg
After exiting lock (screensaver allowed to run), the CPU was 99% for a few
minutes. After some minutes of waiting for a temrinal and firefox to start, they
did actually start, and these are responsive.

Expected results:
Machine should not be brought to it's knees. 

Additional info:
When I previously used azureus with sun java, this issue did not seem to have
occurred, so perhaps it is a gcj issue.
The network is otherwised unused 512/128 ADSL, gkrellm shows max 5KB/sec being
used on eth0, but CPU at 99%. AMD Athlon 2600+. 512M ram.

Comment 1 ajoao 2006-08-19 10:47:35 UTC
i have the same problem with azureus, after some days working a process with the
name "gij" consumes a lot of memory and FC5 is to slow to run anything

Comment 2 Anthony Green 2006-08-19 16:45:18 UTC
(In reply to comment #1)
> i have the same problem with azureus, after some days working a process with the
> name "gij" consumes a lot of memory and FC5 is to slow to run anything


How much memory is it consuming?  How much physical RAM to you have on that system?

Thanks,

AG


Comment 3 Anthony Green 2006-08-20 14:47:40 UTC
I've copied tromey.

I'm able to reproduce this after letting it run overnight with all of the
FC6test2 torrents.  ~300MB resident set size, and ~95% CPU.

One thing I noticed is that the libgcj NIO code throws _a_lot_ of exceptions. 
This was recently fixed upstream, but I don't think the patch is in the libgcj
(4.1.1-17) that I tested:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23682

Another thing I noticed were the messages from the GC about allocating huge
chunks of memory.  I think this is also indicative of a bug.

I'm going to try reproducing this again, and will generate an oprofile report
thigs time.

Comment 4 Anthony Green 2007-11-11 21:29:42 UTC
I'm going to close this with WONTFIX.  We have IcedTea now in F8.  Please run
azureus with IcedTea.


Note You need to log in before you can comment on or make changes to this bug.