Garbage Collection

DSE Version: 6.0

Video

The garabage collector reclaims sections of memory (objects). We must be aware of pauses and throughput when tuning garabage collection. You will learn more about garbage collection in this unit.

Transcript: 

 

You hungry? Yeah, me neither. But the garbage collector is. I tend to think of it like pac man, running around the game board chomping up those little pellets.

The garbage collector's job is to identify and reclaim unused memory on the heap. Think of it as the ultimate file cleanup process, removing all those extra forgotten and sometimes large files. Ahhhh, that would be nice, wouldn't it? Except we aren't dealing with files. The garbage collector reclaims section of memory (objects, if you are familiar with that concept). The sweet spot is to have the garbage collector reclaim memory often enough that we always have enough room to allocate new objects. Yet we don't want it running so often that it bogs down the system. The JVM's heap size affects this. By the way, datastax enterprise six always keeps one core available for garbage collection and other maintenance tasks.

There are two major considerations when tuning your garbage collector: garbage collector pauses and throughput. Some parts of the garbage collection algorithms require your entire Apache Cassandra application to halt. The longer the halt, the more the node appears to the cluster to be down. On the other hand, if you tune your garbage collector to run more often in smaller chunks, the less throughput you'll have as to the overhead incurred as the garbage collector continues starts up and shuts down. Ideally you find that sweet spot or compromise where your node can function acceptably.

Java further breaks down the heap into logical section in order for the garbage collector to do its job. Note the sections at the top: New Generation, Old Generation, and Permanent Generation. You can think of these as levels of how long an object has been around. Kinda like status points on your favorite airline. How many miles have you flown this year? The setup we have here is for concurrent mark and sweep, but the idea is similar to the garbage first algorithm, except it operates on several smaller sections instead.

Let's first look at the new generation area. Java places all brand new objects in the area, starting with the green portion there called "Eden." Sounds biblical. The S in S0 and S1 stands for survivor space, much like the TV show. Here's hoping you make it to the next episode. When the garbage collector kicks in, it starts with all the root references in the object map, that is, the ones referenced from directly from the active call stack and any static references as well. It then follows the nested references all the way down to the leaves marking each object as an active object. Once all objects are marked, the garbage collector then moves them from eden into one of the survivor spaces. An invariant of the algorithm is that one of the survivor spaces is always empty. As the garbage collector copies objects from eden into the empty survivor space, it also copies the active objects from the non-empty survivor space into the target survivor space as well. Once this completes, the active objects are together in one survivor space while the other survivor space is now empty. The process repeats on the next collection, using the new empty survivor space as the target copy location.

The old generation contains objects that have survived long enough to not be collected by a minor GC. These are the objects that are most likely going to be around for a while. When a predetermined percentage of the old generation is full (75% by default in cassandra), the CMS collector runs. Under most circumstances, it runs while the application is running, although there are 2 stop-the-world pauses when it identifies garbage,

However, if the old gen fills up before the CMS collector can finish, it’s a different story. The application pauses while a full GC runs. A full GC checks everything: new gen and old gen, and can result in significant (multi-second) pauses. If you’re seeing multi-second GC pauses, you’re likely seeing major collections happening. If you’re seeing these, you need to fix your gc settings by adjusting the heap size. Also, you may want to consider your data model, because something is creating a LOT of garbage.

No write up.
No Exercises.
No FAQs.
No resources.
Comments are closed.