Removing the hardware issues (faulty memory or disk), that you obviously
already tested, I'll try to give some directions for testing:
a) Main cause of memory leaks are hard references in main class loader.
This happens when you put all your libraries into $TOMCAT_HOME/lib. Try
to move your libraries into WEB-INF/lib and check how does your app behave.
b) Lots of people forget to correctly close external resources (files,
tcp connections, jdbc resources). Check your source code using FindBugs.
It is not perfect, but will give you lots of warnings if you run on risk
of not correctly closing resources. Remember, for jdbc resources, you
should close all result sets first, then all statements, then all
connections (not all database drivers will release resultset resources
on statement close!).
c) Also, we see incorrect thread programming... remember to have a way
to signalize to your threads that the application is closing or
reloading. In my apps, I have a LifeCicly listener that will notify all
threads that they should shutdown immediately. If a thread is stuck
using resources, it will remain with that forever...
d) If your app is JDK6 compatible, give a try on JRockit VM (from
Oracle), and the excellent JRockit Mission Control that helps you to
identify problems in real time.
e) Never store content in static classes. The references stay forever.
If you are using JPA, let JPA implementation to handle the cache. Use
Soft Weak or Hard Weak if using EclipseLink.
f) Never ever use OneToMany just because it is easy. If you have one
object that has OneToMany to other 100, that these has One to many to
another 100, you will have 10001 objects in memory with 1 query that is
supposed to returns 1 record (the first object). If your query returns
10 records of the first object, you would have 100001 object in
memory... If you have 20 users using different objects... well, you got
the point, right?
By using good server hardware (ECC memory, SCSI disks, etc), a stable
linux distro (my preference is for CentOS 64bit), and following the
rules above, I manage to have web apps that run withing 2Gb of memory
(on 8Gb of hardware), hundred of users in databases with > 20Gb, 24x7.
I hope this helps,
Edson Richter
Em 31/01/2013 23:36, Zoran Avtarovski escreveu:
Hi Guys,
We have a application running on the latest Tomcat7 and we are getting a
server crash or becoming unresponsive. This occur every few days at no fixed
intervals or time of day and they certainly don't correlate to any app
function at least not according to the logs.
We set setup monitoring using JavaMelody and what we see is dramatic spikes
in CPU and memory usage at the time of the crash.
Memory hovers around 3-5% for the rest of the time and CPU is the same.
I've looked at the number of sessions, HTTP activity , jdbc activity and
nothing obvious jumps out.
I'd really appreciate your collective wisdom in putting into practice some
strategies to identify the cause of the spikes. This driving me and my team
nuts.
Any help would be appreciated.
Z.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
