Master JVM Tuning: Balancing Pause Time, Throughput, and Memory Usage

Core Insight

The essence of JVM tuning is selecting trade‑offs based on system goals. The two primary objectives are minimizing pause time and maximizing throughput, which cannot be simultaneously achieved when heap usage is fixed.

Pause Time vs. Throughput

Shortest pause time: Stop‑the‑World (STW) GC pauses all application threads, causing visible latency. Critical for latency‑sensitive services.

Maximum throughput: Preferred for batch or background jobs where overall processing speed matters more than individual pauses.

When to Tune the JVM

Old‑generation heap continuously grows to its maximum.

Frequent Full GC events.

GC pause exceeds 1 second.

OutOfMemoryError or other memory‑related exceptions.

Large native (direct) memory consumption.

Overall system throughput or response time degrades.

Optimization Goals (CAP‑like trade‑off)

Only two of the three can be optimized simultaneously: throughput, pause time, and memory usage. Typical quantitative targets (adjust per application) include:

Heap usage ≤ 70 %.

Old‑generation usage ≤ 70 %.

Average GC pause ≤ 1 second.

Full GC count = 0 or average interval between Full GCs ≥ 24 hours.

Step‑by‑Step Tuning Process

Collect runtime data: analyze GC logs and heap dumps to confirm the need for tuning and locate bottlenecks.

Define quantitative tuning goals (e.g., pause ≤ 200 ms, heap ≤ 70 %).

Record current JVM flags (use as baseline).

Prioritize metrics: memory → latency → throughput.

Apply a single change, then compare pre‑ and post‑tuning metrics.

Iterate analysis and adjustment until the desired balance is reached.

Deploy the final flag set to all instances and monitor continuously.

Common Tuning Strategies

1. Choose the Appropriate Garbage Collector

Single‑core CPU: -XX:+UseSerialGC Multi‑core, throughput‑focused: Parallel Scavenge + Parallel Old ( -XX:+UseParallelOldGC)

Multi‑core, low‑latency on JDK 1.6/1.7: -XX:+UseConcMarkSweepGC Multi‑core, low‑latency on JDK 1.8+ with ≥ 6 GB heap:

-XX:+UseG1GC

2. Adjust Heap Size

Frequent GC often indicates a heap that is too small. Increase it, but also watch for memory leaks.

Initial heap: -Xms2g or -XX:InitialHeapSize=2048m Maximum heap: -Xmx2g or -XX:MaxHeapSize=2048m Younger generation size: -Xmn512m or

-XX:MaxNewSize=512m

3. Set Desired Pause Time

Tell the collector the maximum pause you can tolerate; the GC will try to stay within this bound.

-XX:MaxGCPauseMillis=<ms>

4. Adjust Region Size Ratios

Survivor to Eden ratio: -XX:SurvivorRatio=6 (Eden : Survivor = 6 : 1).

Younger to old generation ratio: -XX:NewRatio=4 (young : old = 1 : 4).

5. Tune Tenuring Threshold

Control when objects are promoted to the old generation.

Initial tenuring age:

-XX:InitialTenuringThreshold=7

6. Adjust Large Object Allocation Threshold

Objects larger than this size are allocated directly in the old generation: -XX:PretenureSizeThreshold=1000000 (0 disables the limit).

7. Modify GC Trigger Timing

Start CMS when old generation reaches a certain occupancy: -XX:CMSInitiatingOccupancyFraction=68 (default 68 %).

G1 mixed‑GC live‑region threshold: -XX:G1MixedGCLiveThresholdPercent=65.

8. Increase Native (Direct) Memory

If OutOfMemoryError originates from native memory, raise its limit.

Maximum direct memory:

-XX:MaxDirectMemorySize=<size>

Common JVM Diagnostic Commands

jps – Lists HotSpot JVM processes.

jstat – Monitors class loading, memory, GC, JIT, etc.

jmap – Generates heap dumps ( -XX:+HeapDumpOnOutOfMemoryError can automate on OOM) and reports heap/perm‑gen details.

jhat – Analyzes heap dumps produced by jmap via a lightweight HTTP server.

jstack – Captures thread stack traces of a running JVM or from a core file.

Conclusion

The JVM optimization workflow proceeds from sizing the heap, then reducing pause latency, and finally improving throughput. Each step is iterative: adjust a parameter, measure the impact, and repeat until the defined goals are satisfied.