Re: Session timeout and memory
Re: Session timeout and memory
- Subject: Re: Session timeout and memory
- From: Chuck Hill <email@hidden>
- Date: Wed, 20 Sep 2006 10:14:43 -0700
Hi Owen,
On Sep 19, 2006, at 6:17 PM, Owen McKerrow wrote:
Interesting thread ! And its very similar to a problem Im having.
We are deploying our App under Tomcat and after several days of
running we get and out of memory exception. so we increased the
heap size. We got a couple more days out of the app. So we
increased it again, this time we last 2 weeks, but once again we
have run out of memory.
Sounds like a memory leak. But I guess you knew that. :-)
This leads to a couple of questions :
1) Does anyone know if there is a memory handling issue of WOApps
under Tomcat ? i.e. it never lets the memory go.
I know nothing of that.
2) When we deploy under JavaMonitor we set our apps to restart
themselves regularly. Why's this ? I had thought it may have been a
carry over from Object-C days just to make sure we clean up any
memory leaks. But under Java, one would image it should be all
garbage collected, so why do we still recommend nightly/weekly
restarts ?
FUD, mostly. We have apps that run for weeks or longer without
restarts. Frequent restarts can be a quick "fix" for memory leaks
and other similar issues. If you are running multiple instances, it
is cheap insurance against small, slow problems becoming big problems.
3) Can someone point me at some good doc for learning about memory
profiling of Java app's. Specifically over a long period of time.
Even to figure out how much ram each session is taking and when
that is being garbage collected as per Tom's example below.
Like Tom said, profiling over a long period of time is not something
you want to do. I have run into similar cases and here is what I did:
1. Think. Memory leaks mean that something still has a reference to
some objects. In a WO app this is pretty much the Sessions and the
Application. Do you have anything in the Application that might be
retaining references to objects?
2. Take a close look at sessions. For me, this was the problem.
Various odd exceptions would result in sessions not actually timing
out, or timing out but not getting collected. You must be very
careful of allowing exceptions to escape the constructor, awake,
sleep, and terminate. Exceptions thrown in direct actions may also
cause this. One thing to do is to get a thread dump when the app
runs out of memory. Are a lot of the threads in session methods?
Another thing to do is to log session creation and termination, and
log application(). activeSessionsCount(). If the session count is
always increasing that is a pretty good clue that something is going
wrong in session cleanup.
Chuck
On 19/09/2006, at 6:29 PM, Tom M. Blenko wrote:
What you are seeing is almost certainly just the way garbage
collection works. When the session times out, the objects it
allocated are available for garbage collection. They are not
collected at that time, just made available for collection. The
garbage collector won't run until it needs to.
The latter is not correct. The garbage collector on HotSpot runs
frequently and a common occasion is when a response has been
returned by a WO application. It appears that it collects on these
occasions against the local store. This makes sense in the
immediate context, you'd probably have to test it against you own
applications to determine whether it makes sense on balance. (I
don't believe you can control this behavior in any case).
The garbage collector doesn't collect all available memory on
these occasions, however. I had a disagreement with someone once
about whether the garbage collector would collect a cycle, which
it isn't difficult to create, e.g., off of a session. We put up a
minimal application on a quiet machine, instrumented the VM, set
the session to timeout after 1 minute, requested one page (which
created the cycle), and waited. The garbage collector ran many
times but it took 10 minutes before the cycle was collected.
Behavior of the garbage collector isn't an issue most of the time.
If the working set is close to the VM memory size, however, it can
cause the VM to thrash and the solution is (usually) to increase
the size of VM memory. It can also happen that you know when a
sizable chunk of memory is being freed and forcing the gc to run
amounts to an optimization, e.g., to reduce paging or total memory
use. You can call gc() to advise the garbage collector to run. You
can call gc() three times in succession to advise it more strongly
to run. Running, in this circumstance, will only cause it to
collect what it chooses, it won't necessarily collect all the
memory available.
Tom
Chuck
On Sep 11, 2006, at 11:18 PM, Ute Hoffmann wrote:
Ok, perhaps I'm looking at the wrong thing. This is the piece of
code which I use to determine the used memory:
Runtime runtime = Runtime.getRuntime();
double nochVoranden = new Double(runtime.totalMemory () -
runtime.freeMemory ()).doubleValue();
So this happens to the logs:
The memory goes up inside of the session. It sometimes drops a
bit but it mainly goes up. So there seems to be a memory leak
somewhere...
Ok, but then the session is terminated or times out. So I would
assume that then the memory is returned as free memory.
So the next session should again show used memory lets say 6 MB.
But when the previous session had a used memory of lets say 50
MB the next session (created well after the first session is
timed out or terminated) will show 50MB + of used memory.
And yes: There was only one session present in the testcase and
it clearly went up after the first session was timed out without
releasing this used memory.
Do I have to schedule the instances to get rid of this (as it
happens by design) or does it point me to a memory leak in my
code which means whatever holds the memory cannot be released
even after the session is terminated.
Regards
Ute
Anfang der weitergeleiteten E-Mail:
Von: Q <email@hidden>
Datum: Di, 12. Sep 2006 01:43:35 Europe/Berlin
An: Chuck Hill <email@hidden>
Cc: Ute Hoffmann <email@hidden>, webobjects-
email@hidden
Betreff: Re: Session timeout and memory
On 12/09/2006, at 2:26 AM, Chuck Hill wrote:
In addition to garbage collection which has been mentioned, be
careful of what you are looking at. If additional memory is
allocated to the JVM process, it will not be returned to the
operating system until the JVM process terminates. In other
words, the total heap size will never decrease but free memory
on the heap will vary as objects are created and the garbage
collector runs.
Chuck
It should also be pointed out that this is a good thing not a
liability that needs special consideration, because it means
that the JVM doesn't need to constantly malloc and free memory.
Provided there isn't an actual leak causing the JVM size to
continually grow unexpectedly, the virtual memory allocation
shouldn't be something to really worry about, as any vm pages
that go unused for long enough will eventually get paged out by
the OS should the physical memory be required for something
else. Assuming your OS has got enough swap allocated.
-- Seeya...Q
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_____ / Quinton Dolan -
email@hidden
__ __/ / / __/ / /
/ __ / _/ / / Gold Coast, QLD, Australia
__/ __/ __/ ____/ / - / Ph: +61 419 729 806
_______ /
_\
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve
specific problems. http://www.global-village.net/products/
practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40martingalesystems.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40uow.edu.au
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems. http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden