Skip to main content

Controlling OOME?

2 replies [Last post]
Joined: 2005-02-14

Is there any way to influence an OOME?

I've seen circumstances under which we arrive at a low memory situation (1.4, 1.5) and the garbage collector works exceptionally hard to prevent an OOME but unfortunately the application time to GC time ratio is less very low resulting in poor user experience which means I'd just as soon it died/restarted rather then hobble.

The above scenario lasts for a relatively long time - load based and I believe it was more network load related. ie. near memory threshold, receive remote requests and end up performing GC but fail and get concurrent mode failure (CMS) memory collected but during the collection we end up with more incoming requests which were enqueued by the OS and so immediately after the collection there is a large memory request.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-08-28


This is how I have approached the diagnosis of suchs problem at customer sites.

I think it is best to look at the typically usage consumption of a request and then relate this to a transactional/workload mix. If the numbers do not look good then try throttling the traffic by reducing thread pools or introducing different request pipelines with different pool sizes for better capacity management.



Joined: 2007-05-01

You can certainly have an influence on OOME's, first you need to find out why they are occurring. There are a handful of reasons you might encounter an OOME, from overrunning available Perm or Old spaces, hitting a file descriptor limit, too many open sockets, or even hitting some limit of the C-heap, outside of Java. So, once you understand what is happening, then try to figure out what you can do to avoid the situation. Sometimes the solution is an easily tweaked OS setting or JVM option, other times you might be required to conduct some profiling of your application to see where the pain is.

Try turning on Verbose Garbage Collection logging and then report back what you find. You could also add [b]-XX:+HeapDumpOnOutOfMemoryError[/b] to your JVM options and explore the binary dump to see what is retaining object references.

Please report back what you find. Cheers.