You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by MSerraInsiel <mi...@insiel.it> on 2009/03/20 10:40:40 UTC
Tomcat CPU 100%
Hi all, We have a java web application (deployed on Tomcat 5.5 with java 1.4)
that has never had CPU problems. Some
days ago we deployed a new version, that had non significant differences,
and since this deploy we got frequent CPU
100% usage. users could not work and we needed to rollback to previuos
version.
The unique "structural" difference is the upgrade of the following
libraries, used to generate jasperReports:
- commons-beanutils-1.5 --> 1.7
- groovy-all-1.0-beta-10 --> groovy-all-1.0
- jasperreports-1.2.0 --> 1.3.3
- jdt-compiler --> 3.1.1
- added jasperreports-extensions-1.3.1
with the -Xrs option we could not get info about the hanging thread, so
yesterday we deployed the new version, with
old libraries and without -Xrs option. Now we get no CPU usage problem.
Can you help us understand what the real problem could be?
Thanks in advance
--
View this message in context: http://www.nabble.com/Tomcat-CPU-100--tp22617067p22617067.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat CPU 100%
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MSerraInsiel,
On 3/20/2009 10:48 AM, MSerraInsiel wrote:
> java is 1.4.2, the SO is Linux, but we could not dump the consuming thread
> because of the -Xrs option. Now we removed it, but we have old libraries and
> no CPU problem. In an identical test environment the same problem does not
> arise, even with -Xrs option and new libraries version.
Presumably, a set of upgraded libraries is the goal.
Are you willing to reproduce the circumstances again and take thread
dumps? If not, and you have an "identical test environment" where
everything works fine, I'd say you have a new production environment :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknDrmIACgkQ9CaO5/Lv0PBWpwCgi6fOvUR6nZwZW4LVu84/sbcm
eNwAn1ZAQuWKQdwSgPvQnCS/ZFpssq4n
=aRpq
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat CPU 100%
Posted by MSerraInsiel <mi...@insiel.it>.
java is 1.4.2, the SO is Linux, but we could not dump the comsuming thread
because of teh -Xrs option. Now we removed it, but we have old libraries and
no CPU problem. In an identical test environment the same problem does not
arise, even with -Xrs option and new libraries version.
Any ideas?
Thanks
Christopher Schultz-2 wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> MSerraInsiel,
>
> On 3/20/2009 5:40 AM, MSerraInsiel wrote:
>> Hi all, We have a java web application (deployed on Tomcat 5.5 with java
>> 1.4)
>> that has never had CPU problems.
>
> Take thread dumps while the CPU is pegged. You didn't mention your Java
> version, so here goes:
>
> - - If you have Java 1.5+, you should have the 'jstack' program. Run
> that targeting the pid of the top-level Java process and you should
> get a complete thread dump.
>
> OR
>
> - - On UNIX, send a SIGSTOP to the main java process and look at the
> output in catalina.out.
>
> OR
>
> - - On Windows, you'll need to press CTRL-\ when running Tomcat from the
> command-line. I'm not sure how else to get a thread dump from java
> on Windows, so if you're running it as a service, you might have to
> stop Tomcat, re-start it from the command line (startup.bat) and
> then press CTRL-\ after your CPU goes high.
>
> Take thread dumps a few seconds apart, then examine them. Threads that
> say "BLOCKED" are not using any CPU (at least, not at the time the
> thread dump was taken). Anything that says "RUNNABLE" should be
> inspected to see what it's doing.
>
> Post your thread dumps to the list if you can't figure out what's going
> on.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAknDqpsACgkQ9CaO5/Lv0PAWEwCfcQ3n9YoOFKElIWqdgjf01WHZ
> U8EAn32cdrguG0RUOTGoUCm6vJZV9ozr
> =woZD
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Tomcat-CPU-100--tp22617067p22621751.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat CPU 100%
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MSerraInsiel,
On 3/20/2009 5:40 AM, MSerraInsiel wrote:
> Hi all, We have a java web application (deployed on Tomcat 5.5 with java 1.4)
> that has never had CPU problems.
Take thread dumps while the CPU is pegged. You didn't mention your Java
version, so here goes:
- - If you have Java 1.5+, you should have the 'jstack' program. Run
that targeting the pid of the top-level Java process and you should
get a complete thread dump.
OR
- - On UNIX, send a SIGSTOP to the main java process and look at the
output in catalina.out.
OR
- - On Windows, you'll need to press CTRL-\ when running Tomcat from the
command-line. I'm not sure how else to get a thread dump from java
on Windows, so if you're running it as a service, you might have to
stop Tomcat, re-start it from the command line (startup.bat) and
then press CTRL-\ after your CPU goes high.
Take thread dumps a few seconds apart, then examine them. Threads that
say "BLOCKED" are not using any CPU (at least, not at the time the
thread dump was taken). Anything that says "RUNNABLE" should be
inspected to see what it's doing.
Post your thread dumps to the list if you can't figure out what's going on.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAknDqpsACgkQ9CaO5/Lv0PAWEwCfcQ3n9YoOFKElIWqdgjf01WHZ
U8EAn32cdrguG0RUOTGoUCm6vJZV9ozr
=woZD
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat CPU 100%
Posted by Pid <p...@pidster.com>.
MSerraInsiel wrote:
> Hi all, We have a java web application (deployed on Tomcat 5.5 with java 1.4)
> that has never had CPU problems. Some
>
> days ago we deployed a new version, that had non significant differences,
> and since this deploy we got frequent CPU
>
> 100% usage. users could not work and we needed to rollback to previuos
> version.
>
> The unique "structural" difference is the upgrade of the following
> libraries, used to generate jasperReports:
>
> - commons-beanutils-1.5 --> 1.7
> - groovy-all-1.0-beta-10 --> groovy-all-1.0
Latest stable Groovy is 1.6.
I found 1.0 doing all sorts of things I'd rather it didn't, later
versions are considerably improved.
p
> - jasperreports-1.2.0 --> 1.3.3
> - jdt-compiler --> 3.1.1
> - added jasperreports-extensions-1.3.1
>
>
> with the -Xrs option we could not get info about the hanging thread, so
> yesterday we deployed the new version, with
>
> old libraries and without -Xrs option. Now we get no CPU usage problem.
>
> Can you help us understand what the real problem could be?
>
> Thanks in advance
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org