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

Overview

The article explains how to plan, configure, and optimize JVM settings for a high‑traffic login service that receives about 1 000 000 requests per day on a machine with 8 GB RAM.

Step 1 – Capacity Planning

Estimate per‑second request volume, calculate object allocation size, and decide the number of instances needed. For a peak of 100 requests/s, three 4C8G servers each handling ~30 requests/s are suggested.

Step 2 – Choosing a Garbage Collector

Discusses the trade‑off between throughput and latency, introducing the concepts of throughput and response time. Recommends CMS for low‑latency services and G1 for large‑memory, high‑throughput workloads.

CMS vs G1

CMS is a low‑pause collector for the old generation; G1 is the default modern collector that aims for sub‑10 ms pauses.

Step 3 – Partitioning Heap Regions

Key JVM flags: -Xms and -Xmx set the initial and maximum heap (typically half of system memory), -Xmn defines young generation size, and -Xss sets per‑thread stack size (usually 512 KB–1 MB).

Step 4 – Stack Memory Size

Use -Xss1M for typical services; adjust according to thread count.

Step 5 – Object Age Threshold

Adjust -XX:MaxTenuringThreshold=5 so objects survive five minor GCs before promotion.

Step 6 – Large Object Direct Allocation

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

Step 7 – CMS Old‑Generation Tuning

Typical flags: -XX:CMSInitiatingOccupancyFraction=70, -XX:+UseCMSInitiatingOccupancyOnly, and -XX:+AlwaysPreTouch to start CMS early and pre‑touch memory.

Step 8 – OOM Dump and GC Logging

Enable heap dumps and detailed GC logs:

-XX:+HeapDumpOnOutOfMemoryError

-XX:HeapDumpPath=${LOGDIR}/

-Xloggc:/path/to/gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails

Common JVM Parameter Templates

Response‑oriented (ParNew+CMS) template for a 4C8G machine:

-Xms4g -Xmx4g -Xmn2g -Xss1m -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=10 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseCMSInitiatingOccupancyOnly -XX:+AlwaysPreTouch -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

Throughput‑oriented (G1) template for an 8C16G machine:

-Xms8g -Xmx8g -Xss1m -XX:+UseG1GC -XX:MaxGCPauseMillis=150 -XX:InitiatingHeapOccupancyPercent=40 -XX:+HeapDumpOnOutOfMemoryError -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log

ZGC Overview

ZGC is a low‑latency collector introduced in JDK 11, capable of handling up to 4 TB heap with pause times under 10 ms.

How to Choose a GC

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

Metaspace vs. Permanent Generation

Java 8 replaced the fixed‑size PermGen with native‑memory Metaspace, eliminating the need to set -XX:PermSize and -XX:MaxPermSize. Metaspace grows automatically up to system limits, configurable via -XX:MetaspaceSize and -XX:MaxMetaspaceSize.

Stop‑The‑World, OopMap, and Safepoints

GC pauses require all application threads to stop at safepoints. HotSpot records object reference locations in OopMaps, generated at loop ends, method returns, and possible exception points.

Conclusion

The article emphasizes that JVM tuning is a last‑resort optimization; architectural and code‑level improvements should be prioritized. It also includes promotional notes and links to additional resources.