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

Here's my two cents:

Catching an OutOfMemory error is a waste of time, because by the tim  
eyou get that error all bets ar eoff an dthere is no guarantee that  
the VM is functional.

Here's the pragmatic solution:

1.) Use a MemoryBean or a log messages to periodically check the heap  
consumed. Run with verbose:gc tp see length of major GC pauses.
2.) You should notice that length of GC pauses grows with memory  
consumption. Say at 500MB the average pause is 5 seconds, at 800GB the  
average pause is 8 seconds and your business sponsor says a 6 second  
delay is acceptable. Then 600MB is your memory highwater mark.
3) Configure your heap with -Xms 400MB -Xmx1024 MB
4) Use SItescope/Nagios/monit/custom code to fire an alarm when heap  
used reaches 600MB
5) When you receive the alarm you know its time to do something soon,  
but you also know that you have another 400MB of headroom that should  
prevent an OutOfMemoryError occurring
6) Restart your app at your leisure
7) Rename your app, "Leaky"
8) Buy a copy of the Yourkit Java profiler, determine why the app is  
consuming so much memory and fix the root cause.
9) Have a cup of tea.

On Apr 13, 2008, at 11:41 AM, Randall R Schulz wrote:

> Hi,
>
> My application has highly variable running times and memory demands
> based on the problems submitted to it. Some hard-to-solve (or
> insoluble) problems will run it out of memory.
>
> 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.
> The vast majority of the RAM is used in the search tree, which is
> linked only upwardly from the leaves and the leaves are all in a
> priority queue, so relinquishing the priority queue is enough to make
> all the objects in the tree unreferenceable.
>
> This technique sometimes works and sometimes does not. I.e., when it
> doesn't work the program gets another OOM very shortly after or during
> the my OOM handling and dies.
>
> Until recently, this application was mostly run from the command  
> line so
> this behavior was not such a big problem. Now it's being used much  
> more
> in its Web-App form (running in Tomcat 5.5, at the moment), this
> inadequate handling is becoming a problem.
>
>
> What techniques are available for handling OOM errors in situations
> where simply dying on the spot is not an option?
>
>
> Thanks.
>
> Randall Schulz
>
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com


===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com