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 (athena.apache.org: domain of edsonrichter@hotmail.com
 designates 65.55.111.85 as permitted sender)
Message-ID: <BLU0-SMTP75F1E73D91930E29C99276CF020@phx.gbl>
Date: Sun, 3 Feb 2013 01:41:51 -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: <CD3424BA.34DDA%zoran@sparecreative.com>
In-Reply-To: <CD3424BA.34DDA%zoran@sparecreative.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable

Em 03/02/2013 01:35=2C Zoran Avtarovski escreveu:
> Thanks for the advice.
>
> All libraries are within the apps WEB-INF folder.
>
> It also doesn't appear to be a memory leak. Typically I would expect
> memory use to increase over time with a memory leak=2C but our app shows =
no
> increase just a sharp spike to max allocated memory prior to becoming
> unresponsive.

Which VM are you using?
I had similar problems (even Kernel Panic!) running OpenJDK (default in=20
some Linux distros).

Regards=2C

Edson

>
> For persistence we use Mybatis ORM which we have no issues with on other
> apps.
>
> I've set the GC logging up=2C but because there are no OOME no thread dum=
ps
> are generated.
>
> Z.
>
> On 2/02/13 4:09 AM=2C "Edson Richter" <edsonrichter@hotmail.com> wrote:
>
>> Em 01/02/2013 15:03=2C Edson Richter escreveu:
>>> Removing the hardware issues (faulty memory or disk)=2C that you
>>> obviously already tested=2C I'll try to give some directions for testin=
g:
>>>
>>> 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=
=2C
>>> tcp connections=2C jdbc resources). Check your source code using
>>> FindBugs. It is not perfect=2C but will give you lots of warnings if yo=
u
>>> run on risk of not correctly closing resources. Remember=2C for jdbc
>>> resources=2C you should close all result sets first=2C then all
>>> statements=2C then all connections (not all database drivers will
>>> release resultset resources on statement close!).
>>> c) Also=2C we see incorrect thread programming...
>> When I say (we see..) I want to mean: I see lots of junior programmers
>> doing the same mistake over and over... I don't know if this is your
>> case=2C but I feel that worth to mention here.
>>
>>
>>> remember to have a way to signalize to your threads that the
>>> application is closing or reloading. In my apps=2C I have a LifeCicly
>>> listener that will notify all threads that they should shutdown
>>> immediately. If a thread is stuck using resources=2C it will remain wit=
h
>>> that forever...
>>> d) If your app is JDK6 compatible=2C give a try on JRockit VM (from
>>> Oracle)=2C 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=2C 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=2C that these has One to many to
>>> another 100=2C 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=2C you would have 100001 object
>>> in memory... If you have 20 users using different objects... well=2C yo=
u
>>> got the point=2C right?
>>>
>>> By using good server hardware (ECC memory=2C SCSI disks=2C etc)=2C a st=
able
>>> linux distro (my preference is for CentOS 64bit)=2C and following the
>>> rules above=2C I manage to have web apps that run withing 2Gb of memory
>>> (on 8Gb of hardware)=2C hundred of users in databases with > 20Gb=2C 24=
x7.
>>>
>>>
>>> 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 fixed
>>>> 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
>>>> 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=2C HTTP activity =2C jdbc activi=
ty
>>>> 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=2C e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands=2C e-mail: users-help@tomcat.apache.org
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands=2C e-mail: users-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands=2C e-mail: users-help@tomcat.apache.org
>
>
>


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