From our experience with a Spring app under Tomcat, the JVM memory
configuration looks low.
You might try doubling it and seeing what it does.
The virtual memory of the OS is not as much of an issue since the Tomcat
JVM memory limit will stop it from growing to use the Linux address space.
The GC only affects the JVM cache.
You should make sure that you VM has lots of swap space and then monitor
Linux's use of the swap space to make sure that it is not a problem
outside the JVM.
I am not sure how 6Gb of virtual OS RAM help when the Tomcat app is
restricted to 1Gb.
We found that the examples of Tomcat JVM memory configurations were all
designed for trivial apps.
We had about 50 war files and lots of heavy libraries(JasperReports,
WebServices, Faces, etc.) so we had lots of troubles until we gave
Tomcat some real JVM room to run.
On 31/01/2013 10:58 PM, Howard W. Smith, Jr. wrote:
On Thu, Jan 31, 2013 at 10:32 PM, Zoran Avtarovski
<zo...@sparecreative.com> wrote:
1.The app has been running on Tomcat 7 in a virtualised linux environment
for about 4 months and the issue has been persistent through that time.
Prior to that it was running on a physical Windows server with no issues.
The move to linux coincided with the addition of a substantial amount of
WebServices functionality - consuming.
very interesting, stable on windows (without webservices footprint).
what was your java -version details on windows, and what is your java
-version details on linux?
so the webservices functionality is 'new' software/code? was the code
implemented well for GC? any use of threadlocals? i am only shooting
from the hip, here, as I primarily listen in on topics here, and have
limited experience with java and tomcat.
2.The tomcat instance was originally running with a max of 6Gb of
allocated memory and it would crash almost daily. When we upped it to 11gb
the crashes reduced to about twice a week.
3. Tomcat is configured with the following options export
JAVA_OPTS="-Xms256m -Xmx11460m -Djava.awt.headless=true
-XX:MaxPermSize=256M -XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC"
MaxPermSize seems to me to be too low for a real Tomcat app.
I don't see any point for such a small -Xms256 setting since that seems
to be barely enough to get Tomcat started.
-Xmx11460 seems very high. We did very well with 10% of that number.
4. Xms and MaxPermSize were just reduced from 512m
5. The app generally has about 50-100 concurrent users - the logs show
that Tomcat can crash with as few as 20 users. I'm wondering if it could
be GC related as the crashes often follow periods of heavy use.
6. The app is a struts2 based app using Spring 3.5 for dependancy
injection/ioc.
this is good to know. have you seen/heard of similar reports from
others using struts2 and spring 3.5 for dependancy injection/ioc?
The problem with getting a thread dump is that high CPU usage is only a
spike and server freezes. CPU usage only goes above 5-10% when it's about
to crash. Support then reboot the server instances and off it goes. I've
tried to spend a few days just watching, but of course it didn't skip a
beat while I was monitoring. Is there a way to trigger gather relevant
data when Tomcat crashes?
Z.
I searched tomcat user list, please see below, and consider what was
mentioned there for troubleshooting this issue, and report back here.
http://tomcat.10.n6.nabble.com/Tomcat-suddenly-dies-td4518543.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
