Garbage Collector Performance Comparison

April 10, 2013

Data Grid

For the Red Hat / Intel webinar on big data and JBoss Data Grid (JDG), I executed a performance test against JBoss Data Grid with RadarGun on dedicated Intel hardware. Prior to executing the performance test, I executed a scaled down version of it with a number of garbage collector configurations including the new G1 collector.

Note: Large page memory was configured. (link)

Garbage Collector Configurations



Parallel w/ NUMA (NUMA)

-XX:+UseParallelOldGC -XX:+UseNUMA

Concurrent (CMS)


Concurrent w/ Incremental Mode (iCMS)

-XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode



The following options were not necessary as they are enabled by default:

-XX:+UseParNewGC (enabled with -XX:+UseConcMarkSweepGC)
-XX:+UseLargePages* (disable if large page memory has not been configured)

* With OpenJDK 1.6, UseLargePages is disabled by default.

Hardware / Software Configuration

Physical Servers: 3
Processors / Server: 4

Processor: Intel® Xeon® Processor E7-4860
NIC: 10 GbE (Fiber)

Red Hat Enterprise Linux 6.2
OpenJDK 1.7
JBoss Data Grid 6.1
RadarGun Fork (link)

Performance Test Configuration

Nodes: 30 (10 / Physical Server)
Test Threads / Node: 36

Operations: 80% Reads / 20% Writes
Entry Size: 4,096 Bytes (4K)
Duration: 15 Minutes

Note: The data grid is populated during the warm up phase.

JBoss Data Grid Configuration

Transactions: XA
Transaction Recovery: Enabled
Locking: Pessimistic
Communication: Synchronous

gc_48_sizeI have configured the concurrent collector in incremental mode when executing performance tests in the past. However, with a total of 80 cores per physical server, it would not be necessary to do so when executing this performance test.

I was curious about NUMA. Would the performance of local reads and writes improve with a NUMA aware allocator? No. I’m not sure why. I need to look into this further.

I executed the performance test with the G1 collector twice.
cms_v_g1The first time I executed the performance test with the G1 collector, the concurrent collector not only performed better but there were a number of failed transactions albeit a small number. Then second time, the G1 collector performed better than the concurrent collector but there were still a number of failed transactions. I did not analyze the log files, but I suspect that the transactions failed due to garbage collection.

The performance test was executed with a 4GB of data and an 8GB heap. For the webinar, the performance test would be executed with 34.5GB of data an a 69GB heap. I executed the performance test with an increasing data / heap size incrementally until I reached 34.5GB of data with a 69GB heap.
cms_large_heapThe concurrent collector performed well regardless of the heap size. While the the performance decreased by about 6% from 4GB of data and an 8GB heap to 24GB of data an a 48GB heap, it remained more or less consistent from 24GB of data and a 48GB heap to 34.5GB of data and a 69 GB heap.


The JBoss Data Grid 6.1 webinar introducing new features and detailing cross site replications and rolling upgrades is today at 10:00AM CST. (link)

, ,

About Shane K Johnson

Technical Marketing Manager, Red Hat Inc.

View all posts by Shane K Johnson

3 Comments on “Garbage Collector Performance Comparison”

  1. stuart Says:

    Thanks Shane – interesting post. I am looking at data grid for an application that has low latency requirements – could you post the comparative stop-the-world pause times for each? Or even just make 1 gc log available to download from each test iteration and analyse?


    • Shane K Johnson Says:

      That’s a great idea. However, I no longer have the hardware as it was on loan and I did not enable garbage collection logging. I plan to execute another round of performance tests on separate hardware though. When I do, I’ll enable garbage collection logging.



  1. Garbage Collector Performance Comparison | I ca... - April 10, 2013

    […] For the Red Hat / Intel webinar on big data and JBoss Data Grid (JDG), I executed a performance test against JBoss Data Grid with RadarGun on dedicated Intel hardware.  […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: