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

Problem Statement

During an Alibaba Cloud technical interview, the candidate 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?

Step 1 – Capacity Planning

Estimate per‑second object creation, decide the number of instances, and calculate the required heap size. For a peak of 100 requests/s, three 4C8G machines with a 4 GB heap (2 GB young generation) can handle the load.

Step 2 – Choosing a Garbage Collector

Throughput vs. Latency

Throughput = CPU time spent on application / (application + GC time). Latency = average GC pause time. Larger heaps increase throughput but also pause length; smaller heaps reduce pauses but lower throughput.

GC Options

CMS – low‑latency, suitable for latency‑sensitive services.

G1 – recommended for large‑memory, high‑throughput services.

Typical configuration: young generation uses ParNew, old generation uses CMS, or switch to G1 for newer JVMs.

Step 3 – Partitioning Heap Regions

Set -Xms and -Xmx to half of the physical memory (e.g., -Xms3072M -Xmx3072M for an 8 GB node). Choose -Xmn (young generation) based on workload: stateless web services may use up to 75 % of the heap; stateful services often keep it around 33 %.

Step 4 – Stack Size

Configure -Xss (thread stack) to 512 KB–1 MB depending on the number of threads.

Step 5 – Object Age Threshold

Reduce -XX:MaxTenuringThreshold (e.g., to 5) so objects are promoted to the old generation after fewer minor GCs, preventing premature promotion of short‑lived objects.

Step 6 – Large Object Direct Promotion

Set -XX:PretenureSizeThreshold=1M so objects larger than 1 MB are allocated directly in the old generation.

Step 7 – CMS Tuning

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

These flags start CMS when heap usage reaches 70 % and keep the pause times short.

Step 8 – OOM Dump and GC Logging

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

Enable heap dumps on OOM and detailed GC logs for post‑mortem analysis.

Additional Topics

ZGC Overview

ZGC is a low‑latency collector introduced in JDK 11, targeting sub‑10 ms pauses for multi‑terabyte heaps.

Choosing a Collector

Small heaps (<100 MB) – -XX:+UseSerialGC Single‑core workloads – -XX:+UseSerialGC Throughput‑oriented – -XX:+UseParallelGC Low‑latency – -XX:+UseConcMarkSweepGC, -XX:+UseG1GC, or

-XX:+UseZGC

Metaspace vs. PermGen

Java 8 replaced the fixed‑size PermGen with native‑memory‑backed Metaspace, eliminating the OutOfMemoryError:PermGen issue; size is controlled by -XX:MetaspaceSize and -XX:MaxMetaspaceSize.

Stop‑The‑World and Safepoints

GC pauses occur only at safepoints where the JVM can safely stop all application threads; the OopMap records object references at these points.