OutOfMemory error can occur due to fragmented heap. This issue is not as common as the heap exhaustion but it is a deadly issue regardless.
What are the symptoms of Heap Fragmentation ?
1. Java.lang.OutOfMemory errors in the Application log file
2. Application is not responsive or extremely slow
3. Unexpected errors in user experience
What causes Heap Fragmentation ?
When your application has used up the entire allocated heap (-Xmx) and still needs more, you run into the classic OutOfMemory error. There is simply no more memory available for your application.
What are the symptoms for Heap Exhaustion?
1. Application is not responsive or extremely slow
2. Java.lang.OutOfMemory error in the Application log file
3. Possible Heap Dump file if the Application Server that is running your application is configured to do so
What causes Heap Exhaustion?
GC algorithms/collectors define how GC is expected to behave at run time. There are various Collectors that you can use depending on your need. Note that the collectors vary greatly by the implementation of the JVM. This document addresses Oracle Hotspot JVM.
Note: Unless you explicitly specify a GC collector in the JVM command line, JVM selects the best collector to use based on various factors such as the hardware, platform etc
1. Serial Collector
Simplest. It uses just one thread to perform the GC operation. So, it is suited for single processor machines (are there any still left ?).
Generational heap:
The heap space is primarily divided into two segments as follows:
1. Nursery or Young generation (or Eden)
2. Old or Tenured generation
(There are other segments, and they vary by the JVM vendor. But for the most part understanding the above two segments is enough to troubleshoot GC issues)
As your application runs, the new objects are created in young generation. When the young generation is about to fill up, GC runs what is known as a ‘minor‘ collection and reclaims memory from unused objects in young generation. While at it, the minor collection also moves ‘long lived’ objects to ‘old’ generation. A ‘major‘ collection (a.k.a Full GC), which is invoked when there is serious unmet demand for memory, sweeps through the entire heap to reclaim memory.
It stinks when you don’t throw away of the Garbage
Every java application, whether it is an one line ‘hello world’ application, or an online banking application with millions of users, needs Physical memory to run. And this memory has an upper limit (sorry, you can’t have the cake and eat it too) which is defined by the parameter –Xmx in the Java command line that starts the application.
Example:
Java –Xmx128m HelloWorld
In the above command, 128M is the maximum memory the HelloWorld application can have. This memory is called Heap and it lives in the memory available in the host operating system. As your program executes, it creates Objects, which occupy memory. JVM allocates this memory using available heap.
Software needs memory (RAM) to run. Unfortunately memory is limited. This simply means this: Your application must manage the memory usage effectively or it will suffer.
In a Java application, much of the memory management – scratch that – all of memory management is handled by JVM itself. This is great news for the developers as they don’t need to meddle with ‘malloc’,’free’ and the like. However, due to the fact that every application is different, the out- of-the box JVM memory management may not be efficient.
Garbage Collector is the key element in JVM memory management. In order for your application to run at its maximum speed and reliability, Garbage Collector a.k.a GC must be tuned. GC tuning can be a very time consuming process, mainly because,
1. There are plethora of GC tuning options
2. It takes rigorous testing to identify the effectiveness of the tuning
In the following segments, I will explain how Garbage collector works, the various memory related issues that you might face and how to troubleshoot them. I will also show you few handy tools you can use to speed up troubleshooting.
Coming up: Troubleshooting GC: What is GC and how it works – Part 1
Garbage Collection is a life saver. Sure, you don’t have to mess with malloc() and free() and not worry about accidently deallocating objects that are still being referenced. But is GC a cure-all? Does it save you from all memory issues? Worse yet, can it cause more damage than good? Here are three reasons why GC is overrated:
Application monitoring is vital for any organization. But implementing and maintaining a reliable Application monitoring system can be a very complex process, primarily because of the number of various metrics that can be monitored. In this article, I would like to take you back to the basics, and explain two chief metrics that you must monitor no matter what your application is or does.
One of the deadliest errors you can encounter in your Java application is ‘OutOfMemory’ error. The impact this error can have in your application and your business can be enormous. I have seen organizations spend countless hours struggling to fix this error while continuing to have degraded end-user experience (a sure-fire way to lose credibility). One company was actually restarting their application every three hours just to avoid an ugly hang due to OOM. How sad?
In this article, I would like to point out the most important tuning parameter in your Java application. If you get this wrong, no matter how much tuning you put in, you will end up with an OOM sooner or later. Note that there are tons of tuning parameters available to tune the memory. Most of these may not have any effect at all, and some have game-changing effect. The parameter I’m about to reveal is of later kind and the mother of all parameters. This should be the first parameter you should be analyzing to zero-in.
Without further due, here it is.
Do you know the single biggest reason why some APM solutions fail?
Do you know what you have to do first before you even begin evaluating various APM solutions?
Do you know the hidden cost in any APM system?
Selecting an APM solution can be tedious task. In this free 18 pages eBook, I present 9 criteria to choose a reliable APM with highest ROI. I’ve derived these criteria based on years of supporting Application infrastructure of various sizes. These criteria will help you clearly understand what exactly you should be looking for in any potential APM solution. You will be ready to ask the right questions when you meet with the APM vendor and will not be caught off guard later.
Enjoy the eBook and Good Luck.