Re: Session timeout and memory
Re: Session timeout and memory
- Subject: Re: Session timeout and memory
- From: "Tom M. Blenko" <email@hidden>
- Date: Tue, 19 Sep 2006 01:29:19 -0700
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>,
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:
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:
email@hidden
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:
This email sent to email@hidden