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

During an Alibaba Cloud interview a candidate was asked how to set JVM parameters for a service node with 8 GB memory that must handle 1 million daily login requests; the answer is presented as a step‑by‑step guide covering capacity planning, GC selection, memory partitioning, and concrete flag settings.

Daily 1 M Login Requests – JVM Parameter Design

Step 1: Capacity Planning for a New System

Estimate per‑second object creation size, calculate the memory needed for the young generation, and determine how many servers are required to keep Minor GC pauses acceptable.

Compute object size per request (e.g., 500 B × 20 fields ≈ 10 KB) and scale by request rate.

Choose a machine size (e.g., 4 C 8 G) and allocate a suitable young‑generation size to avoid frequent GC.

Step 2: Choosing the Garbage Collector

Balance throughput versus latency:

Throughput‑oriented: -XX:+UseParallelGC Low‑latency: -XX:+UseConcMarkSweepGC (CMS) or -XX:+UseG1GC, optionally -XX:+UseZGC for very large heaps.

CMS offers low pause times for latency‑sensitive services; G1 is recommended for larger heaps (≥8 GB) where throughput matters.

Step 3: Partitioning Heap Regions

Set -Xms and -Xmx to roughly half of physical memory, then allocate the young generation with -Xmn (or let the JVM decide) and adjust -XX:SurvivorRatio to control Eden/Survivor ratios.

Step 4: Stack Size

Configure thread stack with -Xss1M; large thread counts may require several hundred megabytes of stack memory.

Step 5: Object Tenuring Threshold

Set -XX:MaxTenuringThreshold=5 so objects survive at least five Minor GC cycles before promotion, reducing premature promotion to the old generation.

Step 6: Direct Allocation to Old Generation

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

Step 7: CMS Old‑Generation Optimisation

Typical CMS flags:

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

These start CMS when heap usage reaches 70 % and keep the GC threads ready.

Step 8: OOM Dump and GC Logging

Enable diagnostics:

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

Key JVM Parameter Table

JVM Parameter

Description

Recommended Value

-Xms

Initial heap size

Half of physical memory

-Xmx

Maximum heap size

Half of physical memory

-Xmn

Young generation size

2 GB (for 8 GB node)

-Xss

Thread stack size

1 M

-XX:SurvivorRatio

Eden/Survivor ratio

8

-XX:MaxTenuringThreshold

Object age before promotion

5

-XX:PretenureSizeThreshold

Direct old‑gen allocation size

1 M

CMS GC Process Table

Phase

Description

Stop‑the‑World

1. Initial Mark

Mark roots reachable directly

Yes

2. Concurrent Mark

Trace object graph concurrently

No

3. Final Remark

Fix marks changed during concurrent phase

Yes

4. Concurrent Sweep

Collect dead objects

No

Overall Optimisation Summary

Before launch, estimate request volume and per‑request memory, allocate heap and young‑generation sizes accordingly, choose a GC that matches latency or throughput goals, and fine‑tune flags such as -XX:CMSInitiatingOccupancyFraction or -XX:MaxGCPauseMillis. Ultimately, code‑level and architectural improvements yield the biggest gains, with JVM tuning serving as a final optimisation step.