Concurrent GC is likely to use a lot more RAM than stop and sweep, so increase your heap to 3-4GB and try the concurrent collector again. If that runs out of RAM, go to 64bit Java and keep increasing it, you have 16GB available in the machine...
Peter Johnson of Unisys has a great workshop on tuning Java GC, I saw it at the last CMG meeting, its for members only at: http://www.cmg.org/membersonly/2007/workshops/JavaPerf.zip I googled Peter Johnson Unisys Java and found this pdf, which is part 2 of his workshop. http://www.cecmg.de/doc/tagung_2007/agenda07/fileadmin/trilog/download/cecmg_2007/Referenten/Tag2/2B4_Johnson_JavaPerfII.pdf Hope that helps Adrian On Dec 29, 2007 8:44 AM, Sambasiva Rao Andaluri <[EMAIL PROTECTED]> wrote: > Hi, > We are developing a Java application that consumes real time equity market > data. The application is run on a 2 CPU dual core Opteron box (4 cores with > each 2593Mhz) with about 16GB RAM. The JVM is run in Server mode with 2 GB > heap. Currently we are experiencing some performance issues due to Garbage > collection. JVM uses the default Parallel Garbage collector with 4 threads. > Due to the nature of the application, any stop-the-world garbage collection > activity (for about 7 seconds) is making a huge impact on our application due > to a large number of market data messages (about 1000-3000 messages per sec) > that can queue up application needs to recover or process causing severe > latencies in message processing. We currently using -Xms and -Xmx options set > to the same value for tuning the heap based on Sun's documentation. > > I have couple of questions: > 1. Is there a way to avoid the garbage collection completely by allocating > large amount of heap. > 2. What other JVM options we can use to tune the Garbage collection to make > it quicker. We tried the Concurrent Mark Sweep GC without success (we > encountered an out of memory error within few minutes of application startup) > > I appreciate your help. > > Regards, > Sam > > > This message posted from opensolaris.org > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
