tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian Zara" <adrian.z...@aonhewitt.com>
Subject Re: Tomcat Causes Server to go Panic/Crash
Date Fri, 18 Nov 2011 07:36:36 GMT
Hi Jürgen,

Thanks for the info.

Honestly, I don't know whether it's due to memory outage. But something is 
happening during the shutdown process. As you can see in the JAVA_OPTS 
setting, I have set the max heap size to 1G which is 50% of the total ph
ysical memory and, if I'm not mistaken, I think we are running only one 
application in the tomcat so I don't think it's memory related but still 
not sure. The weird thing is instead that only the tomcat is supposed to 
crash, the whole server does. If I set the AgressiveHeap option is there 
still a possibility to eat up all the availble memory even if I set the 
max heap size?

Best regards,
Adrian




Jürgen Link <juergen.link@googlemail.com> 

11/18/2011 02:59 PM
Please respond to
"Tomcat Users List" <users@tomcat.apache.org>



To
"Tomcat Users List" <users@tomcat.apache.org>
cc

Subject
Re: Tomcat Causes Server to go Panic/Crash






Hi Adrian,

you might want to replace the AggressiceHeap option by a decent initial
heap size, e.g. Xms=64m.
AggressiveHeap seems to eat up all available memory:

[...] The size of the initial heap is calculated based on the size of the
physical memory and attempts to make maximal use of the physical memory 
for
the heap (i.e., the algorithms attempt to use heaps nearly as large as the
total physical memory). (see
http://java.sun.com/docs/hotspot/gc1.4.2/#4.2.2.%20AggressiveHeap%7Coutline
)

Did you investigate the cause of server panic (e.g. crash dump)? Is it
memory related?

Cheers
Jürgen



2011/11/18 Adrian Zara <adrian.zara@aonhewitt.com>

> Hi Chuck,
>
> Thanks for the prompt reply. Please refer to the following requested 
info:
>
> Tomcat version: Tomcat: 5.5.31
> JVM version: gij (GNU libgcj) version 3.4.2 20041017 (Red Hat 
3.4.2-6.fc3)
>
> If the JAVA_OPTS affects the shutdown process, then I have to find out
> what is the best setting for this env variable since I often encounter 
the
> server panic during shutdown. What do you think? Both env variables (
> JAVA_OPTS and CATALINA_OPTS) are used throughout the catalina.sh file so 
I
> cannot remove one and retain the other. Previously, JAVA_OPTS is set to
> '-Xmx512m -XX:+AggressiveHeap' so I thought increasing the heap size to
> 1024 will resolve the server panic. I have two tomcat seated on two
> different machines. When I increased the JVM heap size on the first
> machine and tried to restart a couple of times, I didn't encounter any
> server panic. But when I tried on the other machine, even on the first
> attempt, the server goes to panic. The two machines has the same specs.
> Both tomcats contain the same web application.
>
> Do you think it is really the tomcat settings that causes the server to
> panic? Should I consider using -server mode in the JAVA_OPTS?
>
> Best regards,
> Adrian
>
>
>
>
> "Caldarale, Charles R" <Chuck.Caldarale@unisys.com>
>
> 11/18/2011 01:46 PM
> Please respond to
> "Tomcat Users List" <users@tomcat.apache.org>
>
>
>
> To
> "Tomcat Users List" <users@tomcat.apache.org>
> cc
>
> Subject
> RE: Tomcat Causes Server to go Panic/Crash
>
>
>
>
>
>
> > From: Adrian Zara [mailto:adrian.zara@aonhewitt.com]
> > Subject: Tomcat Causes Server to go Panic/Crash
>
> > Tomcat Version: 5.5.x
>
> Exact Tomcat version?  There have been at least 15 releases of 5.5.
>
> > JAVA_OPTS='-Xmx1024m -XX:+AggressiveHeap'
>
> Note that setting JAVA_OPTS affects all Tomcat Java executions, 
including
> the shutdown process.  You should be using CATALINA_OPTS, not JAVA_OPTS.
>
> > settings in the catalina.sh
>
> You should be creating a setenv.sh script to hold environment variable
> settings, not modifying catalina.sh.
>
> > Server info: Redhat 3.9.2-6.fc3
> >         CPU: 3.4 GHz
> >         Memory: 2GB
>
> Exact JVM version?
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail
> and its attachments from all computers.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
>
>
> The information contained in this e-mail and any accompanying documents
> may contain information that is confidential or otherwise protected from
> disclosure. If you are not the intended recipient of this message, or if
> this message has been addressed to you in error, please immediately 
alert
> the sender by reply e-mail and then delete this message, including any
> attachments. Any dissemination, distribution or other use of the 
contents
> of this message by anyone other than the intended recipient is strictly
> prohibited. All messages sent to and from this e-mail address may be
> monitored as permitted by applicable law and regulations to ensure
> compliance with our internal policies and to protect our business. 
E-mails
> are not secure and cannot be guaranteed to be error free as they can be
> intercepted, amended, lost or destroyed, or contain viruses. You are 
deemed
> to have accepted these risks if you communicate with us by e-mail.
>
>
>




The information contained in this e-mail and any accompanying documents may contain information
that is confidential or otherwise protected from disclosure. If you are not the intended recipient
of this message, or if this message has been addressed to you in error, please immediately
alert the sender by reply e-mail and then delete this message, including any attachments.
Any dissemination, distribution or other use of the contents of this message by anyone other
than the intended recipient is strictly prohibited. All messages sent to and from this e-mail
address may be monitored as permitted by applicable law and regulations to ensure compliance
with our internal policies and to protect our business. E-mails are not secure and cannot
be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or
contain viruses. You are deemed to have accepted these risks if you communicate with us by
e-mail. 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message