The impact of Garbage Collection on Java performance

The impact of Garbage Collection on Java performance

원문:http://blog.dynatrace.com/2011/03/24/the-impact-of-garbage-collection-on-java-performance/

Major GC가 성능면에서 부정적인 영향을 주는 것은 명백 하지만 우리가 주의해야 할 것이 Major GC 만은 아닙니다. 그리고 우리가 항상 Major GC와  Minor GC을 구분할 수 있는 것도 아닙니다.

우리는 Garbage Collector을 튜닝하기 앞서 2가지 주요 튜닝 목표에대해서 알아볼 필요가있습니다.

실행시간대 성능(Execution Time vs. Throughput)

우리가 어플리케이션의 요청과 응답시간의 최소화를 원하는지 최대 처리량을 원하는지 명확히 해두는게 필요하다.

In my last post I explained what a major Garbage Collection is. While a major Collection certainly has a negative impact on performance it is not the only thing that we need to watch out for. And in case of the CMS we might not always be able to distinguish between major and minor GC. So before we start tuning the garbage collector we first need to know what we want to tune for. From a high level there are two main tuning goals.

Execution Time vs. Throughput

The first thing we need to clarify if we want to minimize the time the application needs to respond to a request or if we want to maximize the throughput. As with every other optimization these are competing goals and we can only fully satisfy one of them. If we want to minimize response time we care about the impact a GC has on the response time first and on resource usage second. If we optimize for throughput we don't care about the impact on a single transaction. That gives us two main things to monitor and tune for: runtime suspension and Garbage Collection CPU usage. Regardless of which we tune for, we should always make sure that a GC run is as short as possible, but what determines the duration of GC run?

What makes a GC slow?

Although it is called Garbage Collection the amount of collected garbage has only indirect impact on the speed of a run. What actually determines this is the number of living objects. To understand this let's take a quick look at how Garbage Collection works.

Every GC will traverse all living objects beginning at the GC roots and mark them as alive. Depending on the strategy it will then copy these objects to a new area (Copy GC), move them (compacting GC) or put the free areas into a free list. This means that the more objects stay alive the longer the GC takes.The same is true for the copy phase and the compacting phase. The more objects stay alive, the long it takes. The fastest possible run is when all objects are garbage collected!

With this in mind let's have a look at the impact of garbage collections.

Impact on Response Time

Whenever a GC is triggered all application threads are stopped. In my last post I explained that this is true for all GCs to some degree, even for so called minor GCs.  As a rule every GC except the CMS (and possibly the G1) will suspend the JVM for the complete duration of a run.

The easiest way to measure impact on the response time is to use your favorite tool to monitor for major and minor collections via JMX and correlate the duration with the response time of your application.

The problem with this is that we only look at aggregates, so the impact on a single transaction is unknown. In this picture it does seem like there is no impact due to the garbage collections. A better way of doing this is to use the JVM-TI interface to get notified about stop-the-world events. This way the response time correlation is 100% correct, whereas otherwise it would depend on the JMX polling frequency. In addition, measuring the impact that the CMS has on response time is harder as its runs do not stop the JVM for the whole time and sinceUpdate 23 the JMX Bean does not report the real major GC anymore. In this case we need to use either verbose:gc or a solution like dynaTrace that can accurately measure runtime suspensions via a native agent technology.

Here we see a constant but small impact on average, but the impact on specific purepaths is sometimes in the 10 percent range. Optimizing for minimal response time impact has two sides. First we need to get the sizing of the young generation just right. Optimal would be that no object survives its first garbage collection, because then the GC would be fastest and the suspension the shortest possible. As this optimum can not be achieved we need to make sure that no object gets promoted to old space and that an objects dies as young as possible. We can monitor that by looking at the survivor spaces.

This chart shows the survivor space utilization. It always stays well above 50% which means that a lot of objects survive each GC. If we were to look at the old generation it would most likely be growing, which is obviously not what we want. Getting the sizing right, also means using the smallest young generation possible. If it is too big, more objects will be alive and need to be checked, thus a GC will take longer.

If after the initial warmup phase no more objects get promoted to old space, we will not need to do any special tuning of the old generation. If only a few objects get promoted over time and we can take a momentary hit on response time once in a while we should choose a parallel collector in the old space, as it is very efficient and avoids some problems that the CMS has. If we cannot take the hit in response time, we need to choose the CMS.

The Concurrent Mark and Sweep Collector will attempt to have as little response time impact as possible by working mostly concurrently with the application. There are only two scenarios where it will fail. Either we allocate too many objects too fast, in which case it cannot keep up and will trigger an "old-style" major GC; or no object can be allocated due to fragmentation. In such a case a compaction or a full GC (serial old) must be triggered. Compaction cannot be done concurrent to the application and will suspend the application threads.

If we have to use a continuous heap and need to tune for response time we will always choose a concurrent strategy.

CPU

Every GC needs CPU. In the young generation this is directly related to the number of times and duration of the collections. In old space and a  continuous heap things are different. While CMS is a good idea to achieve low pause time, it will consume more CPU, due to its higher complexity. If we want to optimize throughput without having any SLA on a single transaction we will always prefer a parallel GC to the concurrent one. There are two thinkable optimization strategies. Either enough memory so that no objects get promoted to old space and old generation collections never occur, or have the least amount of objects possible living all the time. It is important to note that the first option does not imply that increasing memory is a solution for GC related problems in general. If the old space keeps growing or fluctates a lot than increasing the heap does not help, it will actually make things worse. While GC runs will occur less often, they will be that much longer as more objects might need checking and moving. As GCs becomes more expensive with the number of objects living, we need to minimize that factor.

Allocation Speed

The last and properly least known impact of a GC strategy is the allocation speed. While a young generation allocation will always be fast, this is not true in the old generation or in a continuous heap. In these two cases continued allocation and garbage collection leads to memory fragmentation

To solve this problem the GC will do a compaction to defragment the area. But not all GCs do a compact all the time or they do it incrementally. The reason is simple, compaction would again be a stop-the-world event, which GC strategies try to avoid. The Concurrent Mark and Sweep of the Sun JVM does not compact at all. Because of that these GCs must maintain a so called free list to keep track of free memory areas. This in turn has an impact on allocation speed. Instead of just allocating an object at the end of the used memory, java has to go through this list and find a big enough free area for the newly allocated object.

This impact is the hardest to diagnose, as it cannot be measured directly. one indicator is a slowdown of the application without any other apparent reasons, only to be fast again after the next major GC. The only way to avoid this problem is to use a compaction GC, which will lead to more expensive GCs. The only other thing we can do is to avoid unnecessary allocations while keeping the amount of memory usage low.

Conclusion

Finally allocate as much as you like, but forget as soon as possible, before the next GC run if possible. Still don't overdo it either, there is a reason why using StringBuilder is more efficient than simple String concatenation. And finally, keep your overall memory footprint and especially your old generation as small as possible. The more objects you keep the less the GC will perform.