Re: Out-of-Memory Handling in Long-Running / Server Applications

The article
>     <http://www.javaspecialists.eu/archive/Issue092.html>
is an interesting read, this part got me thinking:
"Or, you could keep
    a nice big chunk of memory available as reserve, and then
    release that when you are running low on memory, and send a
    warning message to the system administrator."

What I have in mind is something roughly along these lines:
figure out how much memory a typical thread uses, keep a much bigger "chunk of memory" kept away, or simply decide that 20% of available memory are kept as "safety" buffer.

Have a separate "well being" thread that keeps monitoring the amount of available memory, when available memory levels runs low, release that chunk (and send an alarm) and more importantly don't allow any more threads to start with new tasks until other threads finish and memory levels drop to "safe" values,
 then re-take  that "chunk of memory", and so on.

In addition to that,  start the VM with more memory than physical RAM, that way, even if memory runs really low, before the safety buffer is released, you just run the risk of reduced performance due to swapping, once the buffer is released and system is throttled down, it gets a chance to go back to safe operation margins.

Just a few thoughts,

 Erez







> Date: Sun, 13 Apr 2008 13:17:55 -0700
> From: [email protected]
> Subject: Re: [ADVANCED-JAVA] Out-of-Memory Handling in Long-Running / Server Applications
> To: [email protected]
> 
> On Sunday 13 April 2008 13:08, Endre Stølsvik wrote:
> > Randall R Schulz wrote:
> > > Hi,
> > >
> > > When memory is exhausted in the inner loop of the program (the only
> > > place it's going to happen), I catch the OutOfMemoryError, release
> > > the storage, trigger a GC (forcing it would seem desirable, but I'm
> > > not sure how to do that) and report the failure back up the call
> > > chain.
> >
> > Interesting.
> >
> > ...
> >
> > However, I'm a bit sceptical to this, since I believe I've read that
> > after a OOM, you'd better throw away the entire JVM, since it'll be
> > unstable and generally not feeling all that good - and you might get
> > any kind of problems later on.
> 
> One of the biggest weaknesses of the sorts of techniques that you and I 
> are using is that the OOM may be delivered to another thread (instead 
> of or in addition to being delivered to your own).
> 
> The technique presented in the article referred to by Burt B. looks good 
> to me, and I'm in the process of implementing it in my application now.
> 
>     <http://www.javaspecialists.eu/archive/Issue092.html>
> 
> 
> >    Anyone have any information (pointers) about this?
> >
> > Endre.
> 
> 
> Randall Schulz
> 
> ===================================
> This list is hosted by DevelopMentor�  http://www.develop.com
> 
> View archives and manage your subscription(s) at http://discuss.develop.com

_________________________________________________________________
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline