How much RAM does a Java application need?

The heap is not the whole process

When people size a Java server they look at -Xmx. That sets the maximum heap, where your objects live. The operating system sees the whole process, which is larger:

• Heap: your objects, caches and session data, up to -Xmx.
• Metaspace: loaded classes. A framework-heavy application uses 100 to 300 MB.
• Thread stacks: about 1 MB per thread by default. 200 threads is 200 MB.
• Code cache: compiled code, tens of MB.
• Direct and native memory: network buffers, compression, JDBC drivers and native libraries.
• GC overhead: bookkeeping structures of the garbage collector.

As a working rule, expect the process to use the heap plus 300 to 600 MB. If it also shares the server with Nginx, a database and the operating system, add those too.

Our split by default

For a server with a database on it we use about 45% of RAM for the JVM heap, 15% for database buffers and leave 40% for the operating system, metaspace, thread stacks and the file cache. Without a database the heap gets 60%. The bar on the price page shows this for every size.

Typical numbers

These are starting points. Measure your own application under load. Look at the heap after a full garbage collection: that is the live data. Set the maximum to at least twice that.

How to measure

# process memory as the OS sees it
ps -o pid,rss,cmd -C java

# heap, metaspace and GC at a glance
jcmd <pid> GC.heap_info
jcmd <pid> VM.native_memory summary   # needs -XX:NativeMemoryTracking=summary

Signs you need more memory

• The process is killed by the Linux OOM killer, with no Java stack trace in the log.
• java.lang.OutOfMemoryError: Java heap space or Metaspace.
• The garbage collector runs back to back and CPU stays high while throughput drops.
• Swap use keeps growing.

Next: JVM heap settings explained.

Last updated October 29, 2026.