The garbage collection pattern helps you instantly detect the health and performance of your application. In this post, I’ll share a few interesting patterns.
Join the DZone community and get the full member experience. As the author of GCeasy – Garbage collection logs analysis tool, I get to see a few interesting Garbage Collection Patterns again and again. Based on the Garbage collection pattern, you can detect the health and performance characteristics of the application instantly. In this post, let me share a few interesting Garbage collection patterns that have intrigued me. You will see a beautiful saw-tooth GC pattern when an application is healthy, as shown in the above graph. Heap usage will keep rising; once a ‘Full GC’ event is triggered, heap usage will drop all the way to the bottom. In Fig 1, You can notice that when the heap usage reaches ~5.8GB, the ‘Full GC’ event (red triangle) gets triggered. When the ‘Full GC’ event runs, memory utilization drops all the way to the bottom i.e., ~200MB. Please see the dotted black arrow line in the graph. It indicates that the application is in a healthy state & not suffering from any sort of memory problems. When an application is caching many objects in memory, ‘GC’ events wouldn’t be able to drop the heap usage all the way to the bottom of the graph (like you saw in the earlier ‘Healthy saw-tooth pattern). In Fig 2, you can notice that heap usage keeps growing. When it reaches around ~60GB, the GC event (depicted as a small green square in the graph) gets triggered. However, these GC events aren’t able to drop the heap usage below ~38GB. Please refer to the dotted black arrow line in the graph. In contrast, in the earlier ‘Healthy saw-tooth pattern’, you can see that heap usage dropping all the way to the bottom ~200MB. When you see this sort of pattern (i.e., heap usage not dropping till all the way to the bottom), it indicates that the application is caching a lot of objects in memory.
