How to Configure JVM Parameters for a Platform Handling 1 Million Daily Login Requests on an 8 GB Server

The article starts with a real interview question: given a platform that receives 1 million login requests per day and a service node with 8 GB of memory, how should the JVM be tuned?

Step 1 – Capacity Planning

Estimate per‑second request volume, calculate object allocation size, and decide how many instances are needed. For a peak of 100 requests/s, three 4C8G servers each handling 30 requests/s are suggested, allocating 4 GB heap (‑Xms and ‑Xmx) with a 2 GB young generation.

Step 2 – Choosing a Garbage Collector

Discusses the trade‑off between throughput and latency, introducing concepts of throughput = CPU‑time‑for‑application / (application + GC‑time) and response time = average GC pause. Recommends CMS for low‑latency services and G1 for high‑throughput, large‑heap workloads.

CMS vs G1

CMS is a concurrent collector for the old generation, suitable for latency‑sensitive services; G1 is the default in newer JDKs and aims for sub‑100 ms pauses.

Step 3 – Partition Sizing

Key JVM flags: -Xms and -Xmx: set initial and maximum heap size (typically half of physical memory). -Xmn and -XX:SurvivorRatio: configure young generation size (common ratio 8:1:1 for Eden:Survivor:S0). -Xss: thread stack size (usually 512 KB–1 MB).

Example configuration for a 4C8G machine:

-Xms3072M -Xmx3072M -Xmn2048M -Xss1M -XX:MetaspaceSize=256M -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:PretenureSizeThreshold=1M

Step 4 – Tuning Object Age and Large Object Promotion

Adjust -XX:MaxTenuringThreshold (e.g., to 5) so objects survive a few minor GCs before promotion, and set -XX:PretenureSizeThreshold (e.g., 1 M) to allocate large objects directly in the old generation.

Step 5 – CMS Old‑Generation Optimisation

Typical CMS flags:

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

These start CMS early (at 70 % heap usage) and pre‑touch memory to avoid page‑fault latency.

Step 6 – OOM and GC Logging

Enable heap dumps and detailed GC logs for post‑mortem analysis:

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

Metaspace (Former PermGen)

From JDK 8 onward, class metadata resides in Metaspace, which grows dynamically in native memory. Important flags: -XX:MetaspaceSize: initial Metaspace size. -XX:MaxMetaspaceSize: optional upper bound. -XX:MinMetaspaceFreeRatio / -XX:MaxMetaspaceFreeRatio: control GC triggering based on free Metaspace.

Stop‑The‑World (STW) and Safepoints

GC pauses require all Java threads to stop at safepoints. The JVM uses OopMap tables to know which slots contain object references at each safepoint, ensuring correct reference updates during compaction.

Summary

Before launch, estimate workload, allocate appropriate heap and young‑generation sizes, choose a collector that matches latency or throughput goals, and fine‑tune parameters such as survivor ratio, tenuring threshold, and CMS/G1 settings. Complement JVM tuning with code‑level optimisations and thorough performance testing.