Hi Omar, The Sun JDK provides a number of tools which can help you pinpoint the issue.
- I would start monitoring the Java Heap Sizes and Garbage Collection execution as your stress test runs. You can do this with the "jstat -gcutil" command. - If you observe continued heap growth, and no garbage collection happening, then you will want to fine-tune heap sizes and garbage collection policies [1]. - Conversely, if you do see garbage collection occurring but heap size not diminishing, then your objects are being retained in memory. You can use the "jmap" command to obtain stats with the -histo parameters, or save a dump to later analyse it with "jmap". - If you want to dig deeper (and you will probably want to), VisualVM is a great graphical tool to do so. You can see what's taking over your heap and even inspect object by object. Perhaps the second half of this article can help you [2]. Hope this helps. Please get back to us with your findings! [1] http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html. [2] http://marxsoftware.blogspot.com/2009/06/heap-dump-and-analysis-with-visualvm.html Regards, Raúl. On 12 December 2011 04:10, Omar Atia <[email protected]> wrote: > Dear Deckergo, > > The issue in the old gen heap , it keeps growing while running the stress > testing it reaches 1.5 GB and keeps the used heap that size even after > finishing the testing , it keeps the same size I tried GC from JMX nothing > changed . > > Can you advise if I should pass any parameter to JVM for GC ? > > How can I manage to free the old gen heap to back to original state before > doing the stress testing after directly finishing the testing I need to > restore the old heap . > > Thanks, > Omar atia > Sent via BlackBerry® from mtc touch > > -----Original Message----- > From: deckerego <[email protected]> > Date: Sun, 11 Dec 2011 18:00:32 > To: <[email protected]> > Reply-To: <[email protected]> > Subject: Re: Garbage collection Execuation ... > > You can't force garbage collection to happen. You can /request/ that the > JVM > invoke it's configured garbage collector when it's next possible to do so, > but a System garbage collection call is just a prompt and not a forced > invocation. > > Since JMX is enabled on your map, your best bet would be to use the garbage > collection profiling plugin of VisualVM. Watch which portions of the heap > grow - PermGen, Eden, Tenured, etc. That will tell you if you have leaks or > if you are constantly generating new objects and destroying them. It sounds > like you're rapidly marshalling objects, so I'm guessing it's the latter > situation. > > If you have a large number of messages being concurrently marshalled than 2 > GB isn't out of the realm of possibility. You may want to find the average > size of each message being marshalled - both its XML representation as well > as the size of the TCP packet. It's not uncommon for an XML message to be > 10x the size of its bytecode representation. > > It doesn't sound like you have a Camel issue per se, but more of an > application profiling issue. > > > atiato wrote > > > > Can you tell me how can I make garbage collection ? the camel context is > > attached , I didn't use any java code all in XML configuration . > > > > How can I minimize the memory usage to continue making stress testing ? > > should I use garbage collection from jconsole ? can you comment in the > > above command. > > > > Seems with Huge load u need independent Hardware , I 'm having SUN OS > > above . > > > > Camel context is attached . > > > > The camel routes is explained : > > > > From (TCP port) ---> Java Object--> Call WS --> return XML to TCP point > as > > string . > > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Garbage-collection-Execuation-tp5065511p5066978.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
