JVM Parameter Tuning for a Platform Handling 1 Million Daily Login Requests on an 8 GB Node

During a technical interview at Alibaba Cloud, the author was asked how to configure JVM parameters for a platform that receives 1 million login requests per day on a service node with 8 GB of memory. The article presents a step‑by‑step solution that serves both as a practical reference and an interview guide.

Step 1: Capacity Planning for a New System

The first step is to estimate object creation rate, calculate per‑second memory consumption, and decide the number of instances required. Assuming a peak of 100 requests per second, three 4C8G machines (each handling 30 requests per second) are suggested, allocating 4 GB heap (‑Xms and ‑Xmx) with a 2 GB young generation.

Step 2: Choosing the Garbage Collector

Two main goals are considered: throughput versus latency. For latency‑sensitive services, the CMS collector is recommended; for high‑throughput, large‑heap services, G1 is preferred. The article explains the trade‑offs, including stop‑the‑world pauses and GC pause time formulas.

CMS vs. G1

CMS provides low‑latency collection for the old generation, while G1 offers better overall throughput and is the default in newer JDKs. Configuration examples are provided for both collectors.

Step 3: Sizing Heap Partitions

The heap is divided using -Xms (initial heap), -Xmx (maximum heap), -Xmn (young generation size), and -Xss (thread stack). A common rule is to set the heap to half of the physical memory, then adjust the young generation (often 3/8 of the heap, but can be up to 3/4 for stateless services).

Step 4: Thread Stack Size

Thread stack size ( -Xss) defaults to 512 KB–1 MB; with hundreds of threads, the total stack memory can become significant, so it should be tuned accordingly.

Step 5–7: Tuning Object Age, Pre‑tenure Size, and CMS Parameters

To avoid frequent full GCs caused by the dynamic tenuring threshold, the article suggests increasing the survivor space and setting -XX:MaxTenuringThreshold=5. Large objects (>1 MB) can be allocated directly in the old generation using -XX:PretenureSizeThreshold=1M. CMS‑specific options such as -XX:CMSInitiatingOccupancyFraction=70 and -XX:+UseCMSInitiatingOccupancyOnly are also demonstrated.

Step 8: OOM Handling and GC Logging

Enabling -XX:+HeapDumpOnOutOfMemoryError and configuring GC logs ( -Xloggc:/path/gc.log, -XX:+PrintGCDetails, -XX:+PrintGCDateStamps) helps with post‑mortem analysis.

Typical Parameter Templates

-Xms4g
-Xmx4g
-Xmn2g
-Xss1m
-XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=10
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+AlwaysPreTouch
-XX:+HeapDumpOnOutOfMemoryError
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:gc.log

For throughput‑oriented workloads, a G1 template is provided:

-Xms8g
-Xmx8g
-Xss1m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=150
-XX:InitiatingHeapOccupancyPercent=40
-XX:+HeapDumpOnOutOfMemoryError
-verbose:gc
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-Xloggc:gc.log

Summary of Recommendations

Estimate concurrency and memory usage to decide instance count and hardware.

Allocate heap as half of physical memory; tune young generation based on workload characteristics.

Choose CMS for latency‑critical services, G1 for throughput‑critical, large‑heap services.

Adjust survivor ratio and tenuring threshold to keep short‑lived objects in the young generation and reduce full GCs.

Enable OOM dumps and detailed GC logging for troubleshooting.

While JVM tuning can improve performance, the article emphasizes that architectural and code optimizations are usually more effective and should be addressed before resorting to low‑level JVM tweaks.