There are several ways to find out where tomcat is spending all it's cpu
time
1) when it's a 100% CPU eating time issue a few stacktraces at a 10 or
20 seconds interval. then compare all those trace and try to find a
stacktrace which is recurrent. This is clearly not easy and might
require quite a few hours of analysis to point a list of reccurrent
working area during the various dumps. If you have an endless loop of a
very slow process, it should be present in a thread for all dumps.
2) check twice you don't have memory consumption problems. We noticed a
few time here that tomcat behaving very slowly is a prefail warning of a
memory outtage (The garbage collector becomes aggressive). So increase
max memory and max permergensize. (You should get out of memory errors
anyway in the end if this is the case
3) Use a profiling tool to get reports on CPU usage by various areas of
code. When it comes to debugging CPU usage or memory leaks, profilers
are very usefull. The drawback is you have to run your tomcat in a
profiled environnment which will take note of execution time of all your
method calls. If you can't reproduce your problem on a test server ,that
mean you need to profile your production server, but profiling tomcat
render it about 4 to 10 times slower, depending on the profiler, the
memory on server, etc.
2 points in stack trace worth checking, i noticed 2 threads are not in
sleep state and have a similar part in stack trace, check twice if there
is no endless loop around
at br.gov.mds.suasnob.data.pessoafisica.PessoaFisicaData.getPapelList(
PessoaFisicaData.java:185)
at br.gov.mds.suasnob.data.pessoafisica.PessoaFisicaData.getPapeis(
PessoaFisicaData.java:160)
partial traces:
"http-8080-Processor7" daemon prio=1 tid=0x08b6c9f8 nid=0x5048 runnable
[0x6f627000..0x6f6296c0]
at org.hibernate.event.def.AbstractVisitor.processValue(
AbstractVisitor.java:102)
at org.hibernate.event.def.AbstractVisitor.processValue(
AbstractVisitor.java:64)
at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(
AbstractVisitor.java:58)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity
(DefaultFlushEntityEventListener.java:198)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(
AbstractFlushingEventListener.java:190)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions
(AbstractFlushingEventListener.java:70)
at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(
DefaultAutoFlushEventListener.java:39)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java
:711)
at org.hibernate.impl.SessionImpl.prepareQueries(SessionImpl.java:895)
at org.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:885)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:834)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:74)
at br.gov.mds.suasnob.data.pessoafisica.PessoaFisicaData.getPapelList(
PessoaFisicaData.java:185)
at br.gov.mds.suasnob.data.pessoafisica.PessoaFisicaData.getPapeis(
PessoaFisicaData.java:160)
at org.hibernate.engine.ActionQueue.sortCollectionActions(
ActionQueue.java:292)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushCollections(
AbstractFlushingEventListener.java:244)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions
(AbstractFlushingEventListener.java:71)
at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(
DefaultAutoFlushEventListener.java:39)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java
:711)
at org.hibernate.impl.SessionImpl.prepareQueries(SessionImpl.java:895)
at org.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:885)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:834)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:74)
at br.gov.mds.suasnob.data.pessoafisica.PessoaFisicaData.getPapelList(
PessoaFisicaData.java:185)
at br.gov.mds.suasnob.data.pessoafisica.PessoaFisicaData.getPapeis(
PessoaFisicaData.java:160)
at sun.reflect.GeneratedMethodAccessor1697.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491)
at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785)
at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61)
..............
Gustavo Noronha a écrit :
>Hey David!
>
>2006/4/20, David Delbecq <[EMAIL PROTECTED]>:
>
>
>>the kill -3 send a signal, that is you must send it to a process (in you
>>case the java virtual machine). The sun java machine has the behaviour
>>to dump a full stacktrace of all it's threads when it receive this. Of
>>course you won't get the dump in the console where you ran kill it. it
>>will probably be in catalina.out
>>
>>
>
>
>Sure; but do you know a way of relating one of the dumped threads with the
>PID given by top, so I can figure out what thread is eating CPU?
>
>Thanks,
>
>--
>Gustavo Noronha Silva
>Coordenação de Segurança e Sustentação
>Ministério do Desenvolvimento Social - Brasil
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
