Of course, for many applications a full GC is as bad as a crash. Having a large memory process check out for 30 seconds to 5 minutes to do a full GC is just totally unacceptable.
For those applications there are all kinds of settings that enable concurrent and parallel GC to occur. This link might be helpful: http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#icms.recommended_options Some people also recommend explicit and slightly odd sizing of the generations with this: -server -Xms*<size>* -Xmx*<size>* -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:SurvivorRatio=2 -XX:NewRatio=8 That is very similar to what we have used at Deepdyve with good results. Our search engines typically go a few weeks before updates and their memory footprint is completely stable with max GC pauses of < 200ms. Real Soon Now, the G1 collector will be available and stable. But not yet. When that happens, things should get even better. It sounds like your service should be pretty good even without that since it fits into the pattern of all memory allocations being either permanent or so transient that they are garbage in a few seconds. Applications that have long-lived but not permanent cached data will be the ones that will benefit most from G1. On Mon, Mar 15, 2010 at 7:13 AM, kris west <[email protected]> wrote: > I assume the memory creep is causing you issues, not just sleepless nights? > As Bryan mentioned Java (usually) will only GC when it actually runs out of > allocated heap. >
