Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of edsonrichter@hotmail.com
 designates 65.55.111.95 as permitted sender)
Message-ID: <BLU0-SMTP151B7CA8D4280D2DDB02953CF1C0@phx.gbl>
Date: Fri, 1 Feb 2013 15:03:40 -0200
From: Edson Richter <edsonrichter@hotmail.com>
Organization: Simkorp =?ISO-8859-1?Q?Inform=E1tica_Ltda?=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: users@tomcat.apache.org
Subject: Re: Help in diagnosing server unresponsiveness
References: <CD31675F.34C73%zoran@sparecreative.com>
In-Reply-To: <CD31675F.34C73%zoran@sparecreative.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Removing the hardware issues (faulty memory or disk)=2C that you obviously=
=20
already tested=2C I'll try to give some directions for testing:

a) Main cause of memory leaks are hard references in main class loader.=20
This happens when you put all your libraries into $TOMCAT_HOME/lib. Try=20
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=2C=20
tcp connections=2C jdbc resources). Check your source code using FindBugs.=
=20
It is not perfect=2C but will give you lots of warnings if you run on risk=
=20
of not correctly closing resources. Remember=2C for jdbc resources=2C you=20
should close all result sets first=2C then all statements=2C then all=20
connections (not all database drivers will release resultset resources=20
on statement close!).
c) Also=2C we see incorrect thread programming... remember to have a way=20
to signalize to your threads that the application is closing or=20
reloading. In my apps=2C I have a LifeCicly listener that will notify all=20
threads that they should shutdown immediately. If a thread is stuck=20
using resources=2C it will remain with that forever...
d) If your app is JDK6 compatible=2C give a try on JRockit VM (from=20
Oracle)=2C and the excellent JRockit Mission Control that helps you to=20
identify problems in real time.
e) Never store content in static classes. The references stay forever.=20
If you are using JPA=2C let JPA implementation to handle the cache. Use=20
Soft Weak or Hard Weak if using EclipseLink.
f) Never ever use OneToMany just because it is easy. If you have one=20
object that has OneToMany to other 100=2C that these has One to many to=20
another 100=2C you will have 10001 objects in memory with 1 query that is=20
supposed to returns 1 record (the first object). If your query returns=20
10 records of the first object=2C you would have 100001 object in=20
memory... If you have 20 users using different objects... well=2C you got=20
the point=2C right?

By using good server hardware (ECC memory=2C SCSI disks=2C etc)=2C a stable=
=20
linux distro (my preference is for CentOS 64bit)=2C and following the=20
rules above=2C I manage to have web apps that run withing 2Gb of memory=20
(on 8Gb of hardware)=2C hundred of users in databases with > 20Gb=2C 24x7.


I hope this helps=2C

Edson Richter


Em 31/01/2013 23:36=2C Zoran Avtarovski escreveu:
> Hi Guys=2C
>
> 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 fi=
xed
> intervals or time of day and they certainly don't correlate to any app
> function =AD at least not according to the logs.
>
> We set setup monitoring using JavaMelody and what we see is dramatic spik=
es
> 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=2C HTTP activity =2C jdbc activity =
and
> nothing obvious jumps out.
>
> I'd really appreciate your collective wisdom in putting into practice som=
e
> strategies to identify the cause of the spikes. This driving me and my te=
am
> nuts.
>
> Any help would be appreciated.
>
> Z.
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org