On Thu, 22 Oct 1998 15:29:42 -0500, Keith T. Garner wrote:
>I'm out at a clients and we're investigating using Linux, Apache, and
>Jserv in Apache for the new services they want to roll out to their
>customers.
>
>Being a Linux user for years, I have no doubt of its ability, but being
>a company they want to play it safe. I've been doing an unrelisitic-
>for-my-clients-uses tests where a java servlet that speaks over RMI is
>being hit anywhere from 3 to 8 times a second. Its working beautifully
>except I think I may have discovered a memory leak.
>
>When I first ran the test servlet, memory would grow quickly and would
>eventually fill up the heap and cause the vm to exit. After doing some
>quick research I found out that the garbage collection thread was never
>running because it was such a low priority thread and the cpu (and the
>vm) was pegged with requests, so it never got a chance to collect.
>I throw a System.gc() call at the end of the servlet, and the mongo
>growth stopped. However, after 7-10 hours of being pounded on, the
>memory footprint still grows a little bit.
>
>After I stopped the bombing I expected the the vm to shrink a bit, but
>it never did...Which makes me think is a very time memory leak that is
>showing up after constant pounding and a long period of time. And I can't
>figure out if its in the vm, or in something that mod_jserv does to the
>vm.
First, something to do: Have something in the JVM print out the memory
status (used and total memory) or log this every few minutes...
However, I would guess that this is one of two things:
1) A real memory leak - they do happen sometimes in Java (either the
actual VM or the Java code running on it.
2) A fragmentation tractor
This is when memory gets used in just the wrong order and released
in just the wrong order and thus causes memory to get very fragmented.
Normally this requires a memory leak but sometimes, even with no
memory leak this can happen, but only to a certain point.
Things to do:
a) In addition to the call to gc, you can try to force any finalizers to
run. Sometimes objects need to run a finalizer and sometimes that
needs to run on its own thread and... Anyway, this can help in rare
cases.
b) Check that the memory use within the VM is really going up (that
is what the output of the VM memory status is for) If the amount of
memory used does not grow, the problem is not within the Java code
itself. If the amount of total memory does not grow then the
problem is not in the heap space itself but is in an actual JVM memory
leak outside of the Java heap (most likely not)
>I can't track the possible bug down much more then this, which is
>fustrating because its useless as a bug report. However, I do want to
>see if anyone can verify my results.
Do you have the servlet handy?
Which version of the JVM? (Some earlier versions had problems with
threads not freeing all resources)
I have some Java server-side stuff running that tends to be up as long
as the OS stays up. It is still in testing stage but there is a connection
to it at least every 30 seconds with loads as high as one every 2 or 3
seconds during rush hour. (And it has lots of threads but I wrote my
own thread pool class since this was started back when there was a bug
in the Sun code that leaked a bit of memory for every thread you created.)
Michael Sinz -- Director of Research & Development, NextBus Inc.
mailto:[EMAIL PROTECTED] --------- http://www.nextbus.com
My place on the web ---> http://www.users.fast.net/~michael_sinz
