tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: Excessive CPU w/APR Connectors on tomcat-native 1.1.22
Date Thu, 12 Jan 2012 09:55:01 GMT
On 11/01/2012 22:42, Marvin Addison wrote:
> We are seeing excessive CPU burn (top > 300% on multicore machine) in
> multiple versions of Tomcat that use APR connectors exclusively.  The
> problem does not correlate with load.  We initially saw it on 6.0.35
> and subsequently on 7.0.23 as we attempted to upgrade around the
> problem.  We have determined that the component common to both
> versions is tomcat-native 1.1.22.  (We were not seeing this behavior
> on our previous component mix of 6.0.26/1.1.20.)

Can you confirm whether or not the issue exists with 6.0.26 and 1.1.22?
It would be helpful to try and track down which component is the root of
the issue.

How long do the periods of high CPU usage last?

> Graphs of CPU usage over time show a sharp increase when a second
> thread enters sendbb; conversely there is a sharp decrease as soon as
> all but a single thread drop out of the method.  Additionally, there
> may be a correlation with CPU usage and the number of threads in
> sendbb; for example, the CPU burn may be greater when three threads
> are in sendbb versus two.

How sure are you that the CPU is being burned in the threads that are in
sendbb? Just because the CPU usage correlates with threads being in that
method it doesn't necessarily mean that is where the CPU is being used.

> This feels like a concurrency bug: hard to reproduce, sporadic, and
> correlates with number of threads acting on the same code path.
> Please let me know if you'd like me to do anything further that may
> help determine whether this is, in fact, a bug.  I'm happy to create a
> bug report if needed.

Answers to the above questions would help with the analysis of this
issue. Assuming that this is a concurrency issue, then code inspection
is likely to be the best chance of finding the issue. If we can get to a
point where we can say upgrading this one component from x.y.z to
x.y.z+1 triggers the issue that will narrow down where we have to look.

Mark

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


Mime
View raw message