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

During an Alibaba Cloud technical interview the candidate was asked how to set JVM parameters for a platform that receives 1 million login requests per day on a node with 8 GB of memory; the answer below revisits that problem and provides a practical, interview‑ready solution.

Step 1 – Capacity Planning

Estimate per‑second object allocation by calculating the size of each login request object (≈500 bytes for 20 fields) and scaling for RPC, DB, and cache overhead (20‑50×). Assuming a peak of 100 requests per second across three servers (≈30 req/s per server) yields roughly 15 KB of raw objects per second, which can expand to several hundred kilobytes or a megabyte after network and persistence costs.

With a 4 CPU × 8 GB machine, allocating a 4 GB heap (half of physical memory) and a 2 GB young generation provides enough headroom to avoid frequent Minor GCs while keeping the system responsive.

Step 2 – Choosing a Garbage Collector

Two primary goals compete: throughput versus low latency. Larger heaps improve throughput but increase GC pause time; smaller heaps reduce pause time but may increase GC frequency. The article recommends:

For latency‑sensitive services: use ParNew for the young generation combined with CMS for the old generation.

For throughput‑oriented, large‑heap workloads (≥8 GB): use G1GC, which offers predictable pause times.

CMS is described as a concurrent collector with low‑latency benefits but higher CPU usage and possible fragmentation; G1 is the modern default with adaptive pause‑time goals.

Step 3 – Sizing Heap Regions

Typical JVM memory flags:

-Xms3072M
-Xmx3072M
-Xss1M
-XX:MetaspaceSize=256M
-XX:MaxMetaspaceSize=256M
-XX:SurvivorRatio=8

Adjust the young generation ( -Xmn) to about 2 GB (≈2/3 of the heap) for an 8 GB node, yielding an 8:1:1 ratio for Eden:Survivor:S0 (1.6 GB : 0.2 GB : 0.2 GB). This reduces the frequency of Minor GCs.

Step 4 – Thread‑Stack Size

Set -Xss to 1 MB; with hundreds of threads this consumes a few hundred megabytes, which must be accounted for in the overall memory budget.

Step 5 – Object Age Threshold

Lower the default tenuring threshold (e.g., -XX:MaxTenuringThreshold=5) so objects survive only after ~5 Minor GCs (≈150 s) before promotion to the old generation, preventing premature promotion and reducing Full GC pressure.

Step 6 – Direct Promotion of Large Objects

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

Step 7 – CMS Old‑Generation Tuning

Typical CMS flags:

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

These start concurrent collection when old‑gen usage reaches 70 % and ensure memory pages are pre‑touched to avoid page‑fault latency.

Step 8 – Diagnostic Options

Enable heap dumps on OOM and detailed GC logging:

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

Additional Topics

The article also briefly introduces ZGC (a low‑latency collector for TB‑scale heaps), explains why Java 8 replaced the PermGen with Metaspace, and describes the concepts of Stop‑The‑World pauses, OopMap, and safepoints that underpin GC implementations.

Overall, the guide provides a step‑by‑step methodology to evaluate workload characteristics, size the heap, select an appropriate collector, and fine‑tune JVM flags for both latency‑critical and throughput‑oriented Java services.