The decision to use few large memory instances versus many small memory instances lacks a definitive answer, as evidenced by two successful technology companies adopting opposite strategies. Both approaches can work if backed by a competent team. However, large memory configurations are typically more expensive and can complicate performance troubleshooting.
This article discusses useful JVM arguments for handling OutOfMemoryError, which assist in memory troubleshooting. It covers -XX:+HeapDumpOnOutOfMemoryError for capturing heap dumps, -XX:OnOutOfMemoryError for executing scripts, -XX:+CrashOnOutOfMemoryError and -XX:+ExitOnOutOfMemoryError for abrupt application exits, highlighting the importance of graceful handling in both cases.
The article outlines a three-step automated approach to troubleshoot OutOfMemoryError in applications. First, it suggests capturing heap dumps using specific JVM arguments to gather memory data. Next, it recommends restarting the application via a custom script to prevent instability. Lastly, it discusses analyzing heap dumps with tools or an API for effective diagnosis.
Eclipse MAT (Memory Analyzer Tool) is utilized for analyzing heap dumps to address memory issues, distinguishing between Shallow Heap and Retained Heap sizes. Shallow Heap refers to an object's size, whereas Retained Heap indicates memory freed if the object is garbage collected. Examples illustrate these concepts using an object model, revealing how references affect retained heap calculations.
In early 1970s 1 MB was costing 1 million $. Now 1 mb is costing fraction of that cost. There is no comparison. This is one of the reasons why engineers and enterprises don’t worry about memory any more.
In this article, we will see how to analyze a heap dump in detail using ‘jhat’ tool. It’s easier to explain Heap analysis process with an example Memory leak program.
