Thanks Raul ,

After doing what you suggest from dumping heap memory and reading the object 
and classes which has been loaded I figured out that all traffic messages are 
loaded into Old Gen memory , which was because of mock uri added inside the 
route .

I really appreciate your help and pointing me to correct path to fix the issue .

Thanks,
Omar Atia

From: Raul Kripalani [mailto:[email protected]]
Sent: Monday, December 12, 2011 12:34 PM
To: [email protected]; Omar Atia
Subject: Re: Garbage collection Execuation ...

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]<mailto:[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]<mailto:[email protected]>>
Date: Sun, 11 Dec 2011 18:00:32
To: <[email protected]<mailto:[email protected]>>
Reply-To: <[email protected]<mailto:[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.

Reply via email to