Hi Michael Bauer...
Many Thanks,,, this explanations help-me solve many doubts...
( and point out others ... )
I will read this links...
thanks again...
Michael Bauer escreveu:
JVM tuning is tricky business. There are a lot of issues at
play..."catch-22"'s as we like to call them in the states.
For starters, it is correct to increase the max heap if you are
running out of memory. BUT...increase it too much and the JVM doesn't
GC enough, it then falls into a vicious cycle where it never catches
up, and eventually you run out of memory not because you didn't give
it enough, but because you gave it too much.
Same issue with performance. A typical JVM implementation, like the
one from Sun, pauses on full GCs. What I mean by pause is that all
threads stop processing until the full GC is done. In between the
full GCs the JVM will also do some partial GCs, which typically do not
cause this pause. You can see this in action if you enable verbose gc
logging (I think its -verbosegc or something like that). Anyway, this
performance hit can also cause problems if its not well managed.
Keep in mind also that, at least in the Sun JVM, there are multiple
"layers" of memory. In the case of the Sun JVM, there is Eden,
Tenured, and Permgen. Eden is where short-lived object are created
and destroyed. This memory is what gets swiped in the partial GC
runs. If an object lives long enough, its promoted to Tenured.
Eventually, long-lived objects get promoted to Permgen. I bring this
up because you may be running out of Permgen and not running out of
total heap. This was the case with the application I used to support,
in which most of the memory was taken up by long-running service
processes and singletons. Since Singletons stick around for the
entire life of the application (usually), they almost always end up in
Permgen, which by default is set fairly low. You can tune these three
allocations independently.
Last, let me also point out that some applications tend to start
multiple JVMs. For instance the IBM application TADDM starts 7 or 8
JVM instances from within the code directly. This makes it harder to
set the heap sizes as they have to be changes in several places.
There are several things you can do here. First, I would invite you
to read through the whitepaper here:
http://72.5.124.55/docs/hotspot/gc5.0/gc_tuning_5.html
Even if you are not using the Sun JVM, most other JVMs are similar in
how they work.
Next, go check out this tool:
https://cis.med.ucalgary.ca/https/java.sun.com/developer/technicalArticles/Programming/GCPortal/
This is specific to the Sun JVM, but it shows you quite a bit of
information visually, which helps a lot. I know the IBM JVM has a
similar GC analysis tool, which actually was better IMHO than the Sun
tool in that it actually gave suggestions for setting up your heaps.
I believe this is the link to the IBM tool:
http://www.alphaworks.ibm.com/tech/gcdiag
I really hope this helps. I can part by saying that I have been down
this road before, and although the white papers help, they are not
just cut-n-dry. Its going to take some experimentation to figure out
what works for you and what doesn't.
On Apr 25, 2008, at 10:44 PM, Arlindo Luis Marcon Junior wrote:
Hi...
Michael Bauer,,, thanks for your clues...
Yes,,, you are right,,, I need increase the heap size in the server
side...
I do it, but, if I increase more the load over tomcat/axis2, the
resources run out,,, in the same manner... with the same exception...
Without rampart I can increase more and more the load with no
problems...
But, with rampart module engaged, the response time begin to expand
and then throw this exceptions...
I tried put this configurations ( Xms and XmX ) directly in the
tomcat configs,,, in a static manner...
Many thanks for your attention...
Michael Bauer escreveu:
I am no where near an expert in Axis2, but I do know a little about
JVM tuning. This looks to be a problem on your server. I think you
need to increase the MaxHeap size. I believe the setting is
-XmxXXXmb, where XXX is some amount for the size. For instance
-Xmx512m would be 512m. You can usually do 'java -X' to get a
listing of all the special JVM flags.
On Apr 24, 2008, at 9:51 PM, Arlindo Luis Marcon Junior wrote:
Hi All...
I had a simple service inside the tomcat 6.0.14 / axis2 1.3 with
rampart module activated ( with: timestamp, signature and
encryption ).
If I send many messages in sequence,,, I receiced this error below...
=====
ERROR: org.apache.axis2.AxisFault: Java heap space
at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at
org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:528)
at
org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:508)
=====
This is a problem in Axis2 configurations, or in the JVM
(jdk1.6.0_02) configurations,,,
I read some articles related to JVM configs,,, and something like
to expand the size of the JVM heap...
May be,,, axis2 encapsulate the JVW exception in the server side
and send it to me like an Axis2 exception?,,,,
Someone had some cue... about how I can solve this little trouble...
Any help is welcome...
Many Thanks in Advance...
[newbie here]
--
Arlindo Luis Marcon Junior
E-mail: [EMAIL PROTECTED]
Internet Web Page: http://lattes.cnpq.br/6483462042489662
ICQ: 138864173
Curitiba - Paraná - Brasil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Michael Bauer
[EMAIL PROTECTED]
http://www.codechimp.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Arlindo Luis Marcon Junior
E-mail: [EMAIL PROTECTED]
Internet Web Page: http://lattes.cnpq.br/6483462042489662
ICQ: 138864173
Curitiba - Paraná - Brasil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Michael Bauer
[EMAIL PROTECTED]
http://www.codechimp.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Arlindo Luis Marcon Junior
E-mail: [EMAIL PROTECTED]
Internet Web Page: http://lattes.cnpq.br/6483462042489662
ICQ: 138864173
Curitiba - Paraná - Brasil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
