Analysis and Optimization of Frequent Full GC on Two Identical Alibaba Cloud Servers

Two Alibaba Cloud servers with identical CPU, memory, and disk configurations are load‑balanced by Nginx (weight=1). During routine monitoring with Pinpoint, the B server showed a Full GC roughly every eight minutes, causing brief service pauses, while the A server exhibited no Full GC during the same periods.

Pinpoint data for 3‑hour, 6‑hour, and 12‑hour windows reveal that B’s Full GC events occur when the old generation (ParOldGen) reaches about 108 MiB, far below the allocated 896 MiB, leading to frequent collections; A’s heap remains stable with no Full GC.

GC logs confirm that Full GC is triggered by old‑generation space exhaustion. Calculated heap sizes are:

Total heap: 110 592 KiB (≈108 MiB) for the observed logs, later 1 507 328 KiB (≈1 472 MiB) in extended logs.

Old generation: 89 600 KiB (≈87.5 MiB) initially, later 89 600 KiB (≈1 024 MiB).

Young generation: 20 992 KiB (≈20.5 MiB) initially, later 44 832 KiB (≈448 MiB).

Analysis shows that B’s old‑generation size is insufficient for peak load, causing the frequent Full GC, whereas A’s heap (Xms/Xmx = 1536 MiB) comfortably handles the workload.

Optimization strategy for B:

export JAVA_OPTS="-server -Xms1024m -Xmx1024m -XX:+UseParallelOldGC -verbose:gc -Xloggc:../logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"

A’s JVM parameters remain unchanged to continue observation:

export JAVA_OPTS="-server -Xms1536m -Xmx1536m -XX:+UseParallelOldGC -verbose:gc -Xloggc:../logs/gc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"

Running the two different JVM configurations in parallel allows verification of which setting better suits the production environment.