Question

Heap memory size thrashes between 2gigs and ~8gigs about once a minute (see picture).

Relevant details:

• High traffic site
• Lots of physical memory
• Redhat 5.5
• Java 1.6.0_07
• Glassfish 2.2.1 (yes, I know it’s old. no, we can’t upgrade. yes, i know it’s unusual to use as a production app server).
• -XX:MaxPermSize=192m -XX:+AggressiveHeap -Xms14336m -Xmx14336m

I have little experience with memory tuning, but it seems like MaxPermSize is out of whack with Xms and Xmx. Or is this normal?

Answer 1

Why does my JVM heap size thrash from 2gigs to 8 gigs?

There is no evidence that the system is thrashing in the normal (harmful) sense. The sawtooth pattern indicates that objects are being allocated (the up slope) and the GC is then reclaiming them. The allocation rate seems a bit high, but there is every sign that the GC is running efficiently. Indeed, the fact that the heap size is always dropping back to ~2Gb is a good sign, as is the fact that the % CPU usage is low.

I have little experience with memory tuning, but it seems like MaxPermSize is out of whack with Xms and Xmx. Or is this normal?

It looks kind of normal.

Certainly, there’s no need to increase the size of permGen. (PermGen is used for objects that are anticipated to never be garbage collected; typically intern’d Strings¹ and code segments. Normal application objects are never allocated in or moved to permgen space.)

Hypothetically, if you didn’t have lots of memory, the high allocation rate might be a cause for concern. However, you cannot address that by tweaking the GC parameters. You’d need to do some profiling to see what is creating so many objects and see if it is sensible to try to reduce the creation rate. Depending on the application, it may not even be sensible to try.

---

^{1 – In fact, starting with Java 7 intern’d strings live in the regular heap not permgen.}