tags:

views:

153

answers:

1

When attempting to monitor the performance of a JVM using jstat, I see the following lines -

  Timestamp      PC       PU        OC          **OU**       YGC    FGC    FGCT     GCT
      ...
      283.7 132608.0 132304.8   1572864.0    **398734.1**     20     0    0.000    3.061
      284.0 132608.0 132312.8   1572864.0   **1547795.2**     21     0    0.000    3.061
      284.2 132608.0 132313.7   1572864.0    **417220.7**     21     0    0.000    3.418
      ...

The concerned JVM is running with 2.5GB of Eden and 4GB of Max. Heap (-Xmn2560m -Xms4096m -Xmx4096m)

I don't understand how these spikes in Old Gen. usage are possible?

+1  A: 

Totally guessing, but it looks like it happened right as the young gen did a GC which could have kicked new objects into the old generation. That could have caused a more serious compacting pass in the old generation.

I'm guessing it copies over all the new stuff (making the old gen bigger), then compresses it back down... again total guess.

Since you're moving a bunch of stuff over from the young generation, it may take time (and space) to move a few things around even without a full GC.

Bill K
agree with you to an extent! The part I find difficult to believe is when you say "...I'm guessing it copies over all the new stuff (making the old gen bigger), then compresses it back down..." - isn't this a Old. Gen. collection? If so why isn't the FGC count incremented?
spitfire
Yeah, you're right. Still it would be an interesting data point to see if you got that spike every time you get a YGC
Bill K