Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Out of Threads -> Out of Memory ?

40 views
Skip to first unread message

Ben_

unread,
Nov 25, 2004, 7:21:42 AM11/25/04
to
Hello,

An application of ours is suffering OutOfMemory problems.

As we have suspicions that it's not actually running out of memory, we've
been searching for other causes than simply a too small heap or a fragmented
heap. We found some posts mentionning that allocating an excessive number of
threads seemed to turn into an out of memory. We see the process allocates
1000+ threads.

Do you have some information about this ?

Thanks.


Mark Bottomley

unread,
Nov 25, 2004, 6:21:20 PM11/25/04
to

"Ben_" <re...@newsgroup.com> wrote in message
news:41a5ccc1$0$7850$ba62...@news.skynet.be...
Ben:

You didn't mention the VM/plarform you are using, but 1000 threads will
eat
a lot of memory. You may be able to solve it by setting a reduced max stack
for
each thread. I don't know which command line option, but there is one such
for
most VMs.

You might also want to turn on some GC tracing options (again available
on
most VMs) to see whether the heap appears to fragmenting (unlikely on most
better VMs) or if you are truly out of memory. You may also be leaking
memory in JNI calls if you have any.

Mark...


Ben_

unread,
Nov 26, 2004, 1:53:19 AM11/26/04
to
> You didn't mention the VM/plarform you are using
WebSphere 4.0.7 - JDK 1.3.1 - Windows

> You may be able to solve it by setting a reduced max stack
> for
> each thread.

I'll search in the doc.

> You might also want to turn on some GC tracing options (again
available
> on
> most VMs) to see whether the heap appears to fragmenting (unlikely on most
> better VMs) or if you are truly out of memory.

I'm familiar with this and I'll activate it.

> You may also be leaking
> memory in JNI calls if you have any.

Do you know how to see this, beside profiling, because I think verbose GC
logs don't tell JNI's memory usage.

Thx.


JD

unread,
Nov 26, 2004, 11:46:14 AM11/26/04
to

"Ben_" <re...@newsgroup.com> wrote in message
news:41a6d2bb$0$23096$6c56...@feed0.news.be.easynet.net...

Another thing to remember is that OutOfMemoryError could be thrown (I
believe in *nix) when the Java VM cannot obtain a file descriptor from the
OS. So you might be correct if you are holding on to too many file file
descriptors (Sockets, Threads, Files, etc.).


Matthias Ernst

unread,
Nov 29, 2004, 3:35:33 AM11/29/04
to
"Ben_" <re...@newsgroup.com> wrote in message news:<41a5ccc1$0$7850$ba62...@news.skynet.be>...

> As we have suspicions that it's not actually running out of memory, we've
> been searching for other causes than simply a too small heap or a fragmented
> heap. We found some posts mentionning that allocating an excessive number of
> threads seemed to turn into an out of memory. We see the process allocates
> 1000+ threads.

Too many threads will lead to a lack of address space - 1000 stacks +
heap may easily exceed the typically addressable 2GB for a process. I
guess, that's why they called it an OutOfMemory.

At least on Sun VMs - the error message is pretty clear about it,
though: OutOfMemory "unable to create new native thread". To overcome
this, you basically have four options
- create fewer threads (may require changing the application)
- reduce threads' stack size (you may risk StackOverFlowErrors)
- reduce (max) heap size
- move to a 64bit platform

Matthias

0 new messages