Master JVM Tuning: Proven Settings to Eliminate Full GC Pauses

This article explains JVM parameter tuning, a common source of performance headaches where poorly set options cause frequent Full GC cycles, leading to system slowdowns and pauses exceeding ten seconds, especially under heavy traffic of hundreds of thousands of page views per day.

Effective tuning requires a solid understanding of the young generation, old generation, survivor space, and permanent generation, as well as the overall JVM memory management logic, and must be customized to the specific application workload.

After months of practical testing, the author shares the following experience‑based recommendations:

Use a 64‑bit operating system; on Linux, a 64‑bit JDK consumes more memory but offers higher throughput than a 32‑bit JDK.

Set -Xmx and -Xms to the same value, and set -XX:MaxPermSize and -XX:PermSize equally to reduce heap resizing overhead.

Enable detailed GC logging (e.g.,

-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log

) to diagnose issues from the GC log.

When the system stalls, investigate both GC and application code using tools like jmap and jstack; for example, a leak of unclosed URLConnection objects can cause severe slowdown.

Adjust old‑generation size based on cache usage; avoid unbounded HashMap caches and consider LRU‑based maps with appropriate size limits.

Address promotion failures by either removing survivor space ( -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0) or ensuring sufficient old‑generation capacity (e.g., set -XX:CMSInitiatingOccupancyFraction to 70% so CMS starts before the old generation fills).

Periodically restart the Java process because the permanent generation eventually fills up; the author restarts daily.

When using concurrent collection, keep the young generation relatively small and allocate a larger old generation, as concurrent collection minimizes pause impact on other threads.

Based on an 8 GB system handling several million daily page views, the author’s final JVM arguments are:

$JAVA_ARGS="-Dresin.home=$SERVER_ROOT -server -Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M -XX:MaxPermSize=500M -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=90 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log";

Key flag explanations: -XX:SurvivorRatio=65536 and -XX:MaxTenuringThreshold=0 effectively disable survivor space; -Xnoclassgc disables class garbage collection for a slight performance gain; -XX:+DisableExplicitGC prevents accidental System.gc() calls; -XX:+UseParNewGC enables parallel young‑generation collection; CMS‑related flags control concurrent old‑generation collection, with -XX:CMSInitiatingOccupancyFraction tuned so that

(Xmx‑Xmn)*(100‑CMSInitiatingOccupancyFraction)/100 ≥ Xmn

, preventing promotion failures.