Databases 18 min read

Evaluating ZGC vs G1 GC Performance in HBase Clusters

This article examines the challenges of GC pauses in low‑latency HBase services, explains ZGC’s fully concurrent architecture and key techniques such as colored pointers and read barriers, and presents experimental comparisons of ZGC and G1 GC using YCSB benchmarks, highlighting latency, throughput and CPU usage differences.

Big Data Technology Architecture
Big Data Technology Architecture
Big Data Technology Architecture
Evaluating ZGC vs G1 GC Performance in HBase Clusters

This article continues a series on ZGC, focusing on its real‑world garbage‑collection behavior in an HBase cluster and comparing it with G1 GC to verify ZGC’s claimed low‑pause performance.

GC pauses (STW) severely affect latency‑sensitive Java services such as HBase. The authors experienced that, after tuning CMS and G1, the cluster still failed to meet 100 ms response targets and 99.9 % availability for critical workloads, prompting an investigation of ZGC.

The article reviews the stop‑the‑world bottlenecks of CMS and G1, describing the three phases of the mark‑copy algorithm (mark, transfer, relocation) and showing that in G1 the transfer phase is fully STW, which dominates pause time.

It then introduces ZGC’s principles: a fully concurrent mark‑transfer‑relocate cycle with only three brief STW phases (initial mark, final mark, initial transfer). ZGC achieves sub‑10 ms pauses because its STW time depends only on the number of GC roots, not on heap size or live object count.

Key ZGC technologies are explained, including colored pointers that encode object state in high address bits and read barriers that update references on‑the‑fly during concurrent relocation.

For the experiment, a three‑node HBase cluster (24 CPU, 370 GB RAM, 31 GB heap) running CDH 6.3.2‑HBase 2.1.0 was benchmarked with Alibaba’s AHBench (YCSB wrapper). Identical workloads (100 M rows) were executed under G1 and ZGC, while varying only the GC configuration.

Sample ZGC JVM options used: -Xms31G -Xmx31G -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -XX:ConcGCThreads=2 -XX:ParallelGCThreads=6 -XX:ZCollectionInterval=120 -XX:ZAllocationSpikeTolerance=5 -XX:+UnlockDiagnosticVMOptions -XX:-ZProactive -Xlog:safepoint,classhisto*=trace,age*,gc*=info:file=/var/log/hbase/region-server-zgc-%t.log:time,tid,tags:filecount=5,filesize=500m

Results show that ZGC incurs higher CPU usage, especially under heavy load, while G1’s CPU load remains lower. However, ZGC’s pause times stay below 10 ms even during peak load, whereas G1 pauses frequently exceed 100 ms, sometimes reaching several hundred milliseconds.

GC time interval statistics indicate ZGC’s pauses are evenly spaced (≈120 s) as configured, while G1 exhibits irregular, longer pauses. Throughput and latency measurements (read/write throughput, average latency, p99.9 latency) consistently favor ZGC, confirming its advantage for low‑latency workloads despite the CPU cost.

The authors conclude that ZGC can achieve near‑100 % of GC pauses under 10 ms, that its behavior can be tuned via JVM flags, and that it consumes more CPU than G1. They note that results may vary across environments and invite readers to conduct their own tests.

References: https://www.secpulse.com/archives/137305.html http://hbasefly.com/2016/05/21/hbase-gc-1/ http://hbasefly.com/2016/05/29/hbase-gc-2/ http://hbasefly.com/2016/08/09/hbase-cms-gc/

performanceGarbage CollectionZGCHBaseG1GCYCSB
Big Data Technology Architecture
Written by

Big Data Technology Architecture

Exploring Open Source Big Data and AI Technologies

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.