JVM Parameter Tuning for 1 Million Daily Login Requests on an 8 GB Server

Daily 1 Million Login Requests: JVM Parameter Planning

The article presents an interview‑style guide that combines practical JVM tuning with interview preparation, focusing on a scenario where a service processes 1 M login requests per day on a node with 8 GB RAM.

Step 1 – Capacity Planning

Estimate per‑second request volume, calculate object creation size, and decide the number of instances and machine specifications needed to keep Minor GC frequency low.

Step 2 – Choosing a Garbage Collector

Introduce the trade‑off between throughput and latency, explain Stop‑The‑World pauses, and compare CMS, G1 and ZGC. Highlight that CMS is suitable for low‑latency services while G1 is preferred for high‑throughput, large‑heap workloads.

CMS vs G1

CMS uses a parallel young‑generation collector (ParNew) and a concurrent old‑generation collector, whereas G1 provides adaptive pause‑time goals.

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

Step 3 – Partition Ratio Planning

Set -Xms and -Xmx to roughly half of physical memory, allocate -Xmn for the young generation (often 3/8 to 3/4 of the heap depending on stateless vs stateful services), and adjust -Xss for thread stack size.

Step 4 – Stack Size

Typical -Xss values range from 512 KB to 1 MB; large thread counts can consume significant memory.

Step 5 – Object Age Threshold

Reduce -XX:MaxTenuringThreshold (e.g., to 5) so objects move to the old generation only after surviving several Minor GC cycles, preventing premature promotion.

Step 6 – Large Object Direct Promotion

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

Step 7 – CMS Parameter Optimization

Enable concurrent phases, set -XX:CMSInitiatingOccupancyFraction=70 , and add -XX:+UseCMSInitiatingOccupancyOnly and -XX:+AlwaysPreTouch for low‑latency workloads.

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch

Step 8 – OOM Dump and GC Logging

Enable heap dumps on OOM ( -XX:+HeapDumpOnOutOfMemoryError ) and detailed GC logs ( -Xloggc:/path/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps ) for post‑mortem analysis.

What Is ZGC?

ZGC is a low‑latency collector introduced in JDK 11, capable of handling multi‑terabyte heaps with pause times under 10 ms.

How to Choose a Garbage Collector?

Guidelines: use Serial GC for small heaps or single‑core machines, Parallel GC for throughput‑oriented workloads, and G1/CMS/ZGC for latency‑sensitive services.

Why Metaspace Replaced PermGen?

Metaspace resides in native memory and grows automatically, eliminating the fixed‑size -XX:MaxPermSize limitation that caused java.lang.OutOfMemoryError: PermGen space in older JVMs.

Stop‑The‑World, OopMap, and Safepoints

During GC the JVM pauses all application threads at safepoints; OopMap records object reference locations to safely update them.

Conclusion : Proper capacity estimation, partition sizing, GC selection, and parameter tuning are essential to keep a high‑traffic login service stable; however, code‑level and architectural optimizations should be prioritized before resorting to JVM tweaks.