BTW, would Real-Time Java be useful in this kind of environment?? Rayson
On Dec 29, 2007 1:30 PM, adrian cockcroft <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
