Master Tomcat Memory Tuning: Boost Performance Up to 300%

Why Tomcat tuning matters

In enterprise applications Tomcat handles thousands of requests; improper configuration leads to crashes, slow response, and OutOfMemoryError. Proper tuning can increase performance by 200‑300%.

Understanding Tomcat memory model

JVM memory structure

JVM memory consists of heap (young and old generations) and non‑heap areas such as method area, PC register, and VM stack.

Heap Memory : Young Generation (Eden + 2 Survivor), Old Generation.

Non‑Heap Memory : Method Area, PC Register, VM Stack.

Common OutOfMemoryError types

// OutOfMemoryError: Java heap space - heap overflow
List<Object> list = new ArrayList<>();
while (true) {
    list.add(new Object[1024*1024]); // 1 MB each
}

// OutOfMemoryError: Metaspace - method area overflow
while (true) {
    Enhancer enhancer = new Enhancer();
    enhancer.setSuperclass(Object.class);
    enhancer.setCallback(NoOp.INSTANCE);
    enhancer.create(); // dynamic class generation
}

Tomcat JVM parameters deep tuning

Core memory parameters

Set JVM options in catalina.sh or catalina.bat:

# Basic memory
JAVA_OPTS="$JAVA_OPTS -server"
JAVA_OPTS="$JAVA_OPTS -Xms2048m"   # initial heap
JAVA_OPTS="$JAVA_OPTS -Xmx4096m"   # max heap
JAVA_OPTS="$JAVA_OPTS -XX:NewRatio=3"
JAVA_OPTS="$JAVA_OPTS -XX:SurvivorRatio=8"

# Garbage collector
JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"
JAVA_OPTS="$JAVA_OPTS -XX:G1HeapRegionSize=16m"

# OOM handling
JAVA_OPTS="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError"
JAVA_OPTS="$JAVA_OPTS -XX:HeapDumpPath=/opt/tomcat/logs/heapdump.hprof"

Practical tuning strategies

High‑concurrency web apps:

# Example for high‑concurrency short‑request workloads
JAVA_OPTS="-server -Xms4g -Xmx4g -XX:+UseG1GC \
 -XX:MaxGCPauseMillis=100 -XX:+UnlockExperimentalVMOptions \
 -XX:+UseCGroupMemoryLimitForHeap -XX:+PrintGC \
 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps"

Memory‑intensive apps:

# Example for large cache workloads
JAVA_OPTS="-server -Xms8g -Xmx8g -XX:+UseConcMarkSweepGC \
 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSInitiatingOccupancyOnly \
 -XX:CMSInitiatingOccupancyFraction=70"

Monitoring and diagnostics

JVM built‑in tools

# 1. jstat – GC statistics
jstat -gc <pid> 250ms 10

# 2. jmap – heap dump
jmap -dump:live,format=b,file=heap.hprof <pid>

# 3. jstack – thread dump
jstack <pid> > thread_dump.txt

A sample bash script continuously prints GC and CPU usage for a Tomcat process:

#!/bin/bash
while true; do
    echo "=== $(date) ==="
    jstat -gc $(pgrep java) | tail -1
    echo "CPU: $(top -p $(pgrep java) -b -n 1 | grep java | awk '{print $9}')"
    sleep 30
done

Connector tuning

Key connector parameters in server.xml:

<Connector port="8080" protocol="HTTP/1.1"
    connectionTimeout="20000"
    maxConnections="2000"
    maxThreads="500"
    minSpareThreads="25"
    acceptCount="1000"
    enableLookups="false"
    compression="on"
    compressionMinSize="2048"
    URIEncoding="UTF-8" />

Formula for optimal maxThreads: CPU cores × 2 × (1 + wait‑time/processing‑time).

Database connection pool

Example HikariCP configuration in context.xml:

<Resource name="jdbc/MyDB" auth="Container"
    type="javax.sql.DataSource"
    factory="com.zaxxer.hikari.HikariJNDIFactory"
    driverClassName="com.mysql.cj.jdbc.Driver"
    jdbcUrl="jdbc:mysql://localhost:3306/mydb?useSSL=false"
    username="myuser"
    password="mypass"
    maximumPoolSize="50"
    minimumIdle="10"
    connectionTimeout="30000"
    idleTimeout="600000"
    maxLifetime="1800000"
    leakDetectionThreshold="60000" />

Garbage collector selection

G1GC (recommended for >6 GB heap)

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:G1HeapRegionSize=16m
-XX:G1MixedGCCountTarget=8
-XX:+G1PrintRegionRememberedSetInfo"

CMS (low‑latency workloads)

JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=70
-XX:+CMSScavengeBeforeRemark"

GC log analysis script

#!/bin/bash
gc_log="/opt/tomcat/logs/gc.log"
echo "=== GC frequency ==="
grep "GC(" "$gc_log" | wc -l
echo "Full GC count:"
grep "Full GC" "$gc_log" | wc -l
echo "=== Average GC time ==="
grep -o "[0-9]*\.[0-9]*ms" "$gc_log" | sed 's/ms//' | awk '{sum+=$1; n++} END {print "Avg GC time:", sum/n "ms"}'
echo "=== Max GC time ==="
grep -o "[0-9]*\.[0-9]*ms" "$gc_log" | sed 's/ms//' | sort -n | tail -1 | xargs echo "Max GC time:"

Key take‑aways

Proper memory sizing : allocate 70‑80 % of physical RAM to the JVM.

Select appropriate GC : G1GC for large heaps, ParallelGC for smaller ones.

Optimize connector settings : tune maxThreads, maxConnections, etc., based on real concurrency.

Comprehensive monitoring : use jstat, jmap, custom scripts, and alerting.

Regular maintenance : clean logs, analyze GC logs, and tune database queries.