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

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

During an Alibaba Cloud technical interview a question was asked: Assuming a platform receives 1 million login requests per day and each service node has 8 GB of memory, how should the JVM parameters be set? The following guide walks through the analysis, modeling, and concrete JVM settings.

Step 1: Capacity Planning for a New System

Estimate per‑second object allocation and memory consumption, decide the size of the young generation, and calculate how often Minor GC will be triggered. For a 4C8G machine running three instances, allocate 4 GB heap (‑Xms and ‑Xmx) with a 2 GB young generation (‑Xmn) to keep Minor GC pauses reasonable.

Practical Example

Peak load: 100 login requests per second.

Each request creates an object of ~500 bytes (≈15 KB per second for three instances).

With a 2 GB young generation, Minor GC occurs roughly every few hundred seconds, which is acceptable.

Step 2: Choosing a Garbage Collector

Introduce throughput vs. latency trade‑offs. For low‑latency services, CMS (Concurrent Mark‑Sweep) is recommended; for high‑throughput large‑heap services, G1 is preferred.

CMS vs. G1

CMS: concurrent collection, low pause, but higher CPU usage and possible fragmentation.

G1: region‑based, aims for sub‑100 ms pauses, better for heaps >4 GB.

Step 3: Sizing Heap Regions

Set -Xms and -Xmx to half of physical memory (≈4 GB for an 8 GB node). Configure the young generation with -Xmn (e.g., 2 GB) and -XX:SurvivorRatio=8 to obtain an 8:1:1 Eden:Survivor:Survivor split.

Step 4: Thread Stack Size

Use -Xss1M (default 512‑1024 KB) depending on the number of threads.

Step 5: Object Tenuring Threshold

Adjust -XX:MaxTenuringThreshold=5 so objects survive five Minor GCs before promotion, reducing premature promotion to the old generation.

Step 6: Direct Allocation of Large Objects

Set -XX:PretenureSizeThreshold=1M to allocate objects larger than 1 MB directly in the old generation.

Step 7: CMS Parameter Tuning (for 4C8G systems)

-XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch

Step 8: Enable OOM Dumps and GC Logging

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=${LOGDIR}
-Xloggc:/path/to/gc.log
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

Full JVM Parameter Template (Response‑First, ParNew+CMS)

-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
-XX:+PrintGCTimeStamps
-Xloggc:gc.log

G1 Template (Throughput‑First, 8C16G system)

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

Optimization Summary

Estimate business load and allocate heap accordingly.

Choose GC algorithm based on latency vs. throughput requirements.

Prefer code‑level and architectural optimizations before JVM tuning.

By following these steps, the JVM can be configured to handle the expected load while keeping pause times within acceptable limits.