Reputation: 61616
C# dev here, forced to deal with Java... I am interfacing to a Java Web Service, which is quite memory and CPU heavy. It .
Facts:
Every now and then, the web service is hit by Garbage Collection storms and it slows down processing (as determined by the vendor of the Java Web Service).
My question, not knowing much about Java GC, is why does GC even kick in if there is plenty of RAM available. Is there some setting which tells it to kick when there is little memory left?
My frame of reference is the .NET GC, which only kicks in when there is memory pressure.
Upvotes: 2
Views: 2711
Reputation: 407
It could be that the size of the different generations is not sized correctly.
A good article about this is http://java.sun.com/docs/hotspot/gc1.4.2/
Upvotes: 1
Reputation: 150108
There are several garbage collection models available in Java. You can experiment to see which one has the least impact in your particular use case. See:
I was able to get much smoother / predictable performance in a web service a while back by selecting an appropriate collection model.
Upvotes: 7
Reputation: 31724
Frankly there can be a lot of reasons for this behaviour. Under the above said circumstances you will probably have to tune the garbage collector according to your results. Oracle has an excellent resource on it at http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
Basically in short for the default GC, there are 2 types of runs: 1) Partial GC where objects which young in age are deallocated. 2) Full GC where Garbage Colelction is run over all the objects.
Can you please provide your log with arguments as -XX:+PrintGCDetails -XX:+PrintGCTimeStamps . Your delay might be due to a Full GC as partial GC is normally sweet to damage. As you said there is a lot of RAM available but can you please specify the heap size allocated. It at all the damage is due to partial GC (probability is low), then once try with concurrenct mark and sweep by using +UseConcMarkSweepGC as it is custom made for high losses in partial GC
Upvotes: 3
Reputation: 7306
Most Java garbage collectors only run as needed.In general, more memory causes less frequent, longer garbage collections.The GC is typically lazy, meaning it will only start really trying to reclaim memory internally when the heap is at its maximum size. If you didn't set an upper limit, the runtime would happily continue to inflate until it used every available bit of memory on your system.
Sun JVM uses a fixed upper limit for the size of its memory allocation pool(-Xmx).You can manually change the limit (parameter -Xmx)
Upvotes: 2
Reputation: 100040
What you need is a profiler. Two good options are JProfiler and YourKit. Either will show you exactly what is going on, so that neither you nor the people here have to try guessing.
Given what you wrote, there is no way to know whether the application is simply allocating up a storm that the GC eventually has to catch up with, or something more exotic.
Upvotes: 4