Pathological Behaviour with Garbage Collection?
I'm experiencing what I believe to be very strange behaviour in the GC...
Running JDK 1.3.1 on Solaris, at a certain point the JVM starts doing a large number of Full GC's - and doesn't stop (one every couple of seconds - each taking up to 1 second of CPU). This can consume up to 60% of the CPU when the application (Resin Servlets) is doing very little.
The current invocation uses -Xmx1024k to set the upper heap size, and this strange behaviour seems to start when the heap grows to about 130k - and doesn't stop even if it shrinks.
Adding a -Xms256k (for example) to the invocation just makes matters worse. In this case the verbose:gc switch shows it doing a Full GC every couple of seconds as soon as the application is started.
Has anyone any experience of similar behaviour - or ideas about how to progress the diagnosis?
[880 byte] By [
piersc] at [2007-9-26 8:57:38]
This behavior is not unusual is due to the cost of Full GC's since the new genetion portion of the heap will be very, very small. Running a servlet engine with less than is pretty optimistic, to say the least.
Consider something like this to get the best performance of a server application (the ratios of the memory parameters should remain the same as you grow/shrink the total size):
java -server -Xms64m -Xmx64m -XX:NewSize=32m -XX:MaxNewSize=32m -XX:SurvivorRatio=2 ...
Chuck
Yes - I have tried almost every combination of flags, both supported and not supported. They make subtle differences to the behaviour - such as changing the heap size at which the instability sets in.
In fact increasing NewSize appears to make the problem worse. The verbose:gc output shows that there is very little scavanging going on, but an excessive use of the Full GC (=mark/compact I believe).
> Yes - I have tried almost every combination of flags,
> both supported and not supported. They make subtle
> differences to the behaviour - such as changing the
> heap size at which the instability sets in.
>
> In fact increasing NewSize appears to make the problem
> worse. The verbose:gc output shows that there is very
> little scavanging going on, but an excessive use of
> the Full GC (=mark/compact I believe).
Can you post some example verbose:gc output? Also, about how often is the Full GC occuring? Have you tried to modify the the Sun RMI system properties to lengthen the time between DGC-induced full GC's (the default is 60 seconds)?
Chuck
