Understand True Utilization of Memory Pools
Using a solution like AppDynamics you can easily monitor the different memory pool sizes over time to understand just how close your application is to getting a Java memory leak so you can better fine tune your JVM memory settings and prevent Java memory leaks. For example, OutOfMemory Exceptions can occur when PermGen space is exhausted by application code that is sometimes bigger than the default Perm Gen space in memory, typically 64 to 128MB.
Don't Fear Large Amounts of Data
Another common reason for OutOfMemory exceptions is when the application queries large amounts of data from relational databases and tries to persist and process it in JVM memory. With AppDynamics you can perform memory leak detection and also track heap usage over time, object count and physical size (MB) of the objects residing in memory, giving you great visibility into how much data is being persisted in the JVM at any one time and how much of your memory is being exhausted by different types objects and data structures. You can also correlate this information with garbage collection cycles to understand how often memory is reclaimed by the JVM. Garbage Collection is a "stop the world" event in the JVM so it's important to identify how frequently this occurs and what impact it can have on your application response times.
Identify the Source of Memory Leaks & Fast
If you do have memory leaks in Java, let's face it: spending hours trawling through thread dumps and profilers isn't fun. And you don't want to try a heap dump when the overhead could potentially bring down your app. But AppDynamics' Java memory leak detection can spot and flag leaking data structures:
AppDynamics automatically tracks the size and growth of Java Collections like HashMap, HashSets and ConcurrentLinkedQueues over time as data in your application is requested and persisted within JVM memory. AppDynamics uses intelligent algorithms to detect which Collections may potentially be leaking, and flags these Collections automatically so users can drill-down, and inspect the contents, to better understand what objects are being allocated, and how much memory these objects are consuming inside the Collection.
For example, in the above screenshot we can see that 109, 377 String objects have been allocated to a collection which occupies approximately 46MB of memory. Once we know what types of objects have been allocated, the next step is to determine what application code is allocating those objects so we can fix the memory leak. We can so this by using the "Access Tracking" feature as shown below, this shows which code path is performing object allocation (put()) on the leaking Collection. In the example below, its the collectionleak.dosomework() method which is adding to the HashSet Collection. We can also identify the business transaction "purchase order" is responsible for this code path so we can determine the real root cause and business impact of the memory leak.
More about AppDynamics
AppDynamics provides an easy to way to monitor and manage memory and identify memory leaks. Unlike many memory monitoring tools (or logging), AppDynamics can run in your production environment without adding too much overhead -- this means you can now troubleshoot and resolve memory-related issues in your production application without having to worry about affecting end user experience.