CODEWITHSUNDEEP
javatomcatjvmheap-memory
Blankman
Blankman

Reputation: 267040

Explanation of running jmap on my tomcat pid

I modified my catalina.sh with this on the top:

export CATALINA_OPTS="-Xms512m -Xmx1500m"

I have 4GB ram on my server, and I am load testing so I want to give everything to tomcat pretty much.

What other JVM settings should I be tweaking to maximize requests per second?

Is PerMem important also?

I'm a bit confused as to the jmap output below.

I set Xmx to 1500megs, which it seems to have updated as I see the 'maxheapsize' is 1500m.

But where does it show how much the heap I've used and how much is free?

I see under heap usage 63mb (eden), What is that?

enter image description here

Upvotes: 2

Views: 1664

Answers (1)

Greg Bowyer
Greg Bowyer

Reputation: 1684

The hotspot (read sun) heap is split into several parts, so when you specify -Xmx you are really setting a maximum for the entire heap, and not part of it.

Eden is a small part of the overall heap, its kept small to ensure that the application does not stop for long periods of time during collection. All new objects (that fit) go into eden to start with, if they are not garbage they will get promoted to either the survivor spaces or tenure.

Survivor (The To/From space) is a place for the GC to try to get objects that might be garbage, but could not be worked out quickly during eden collection, there are two survivor spaces which act as buffers, as one is filled by the GC the other is drained into tenure, if you were to watch the graphs you will see these two spaces flipping over in usage.

Tenure is where long lived objects reside, this heap is typically quite large and is collected by a different algorithm to that of eden.

Perm is somewhat separate to the rest of the heap, it is where constant strings (any string that has been "interned") and class bytecode live. It is very rare that you need to tune it, typically it only needs to be increased for huge applications, or for applications that (badly) auto-generate code.

Without pause times I cannot really say if you have your JVM settings quite right, but from your heap sizes you appear to be using roughly 1.2 Gb of your allocation. Unless your application is seeing any nasty pauses I would think that you are done with GC tuning (people often go to town on a huge number of flags without really understanding what they do, leave the flags be until you have proven to yourself that they are needed)

You are aiming for low latency on web applications so the usage of ConcurrentMarkSweep as the tenure collector is a sane choice.

Upvotes: 1

Related Questions