André Warnier wrote:
Justin Randall wrote:
Hello,
From a general Linux perspective, if you have a knowledge of Linux
system calls,
not really
along with what operations are performed by which web application
not really either. Basically, that is what I am trying to find out.
(One might wonder what I really do know, I know. My colleagues also
wonder.)
I see (with top) that Tomcat as a process is busy doing something, but
what I don't know is what within Tomcat is doing it.
This Tomcat runs a number of webapps, a minority of which I really
have an idea of what they are supposed to be doing. And precisely
these should not be doing anything at the times I'm watching. So my
suspicion is one of the others, but I may be wrong, and that's what I
am trying to figure out.
you could use "strace" (use the -f to follow threads). Depending on
what you're interested in you can filter further for operations on
files or network activity (i.e. "-e trace=file,network,desc"). If you
see a lot of erroneous activity (such as constantly trying to
open/stat a file that doesn't exist) and you know which web app (or
Tomcat) is responsible you can address the issue.
You could also check "top" to see whether the CPU is being consumed
in usr or sys space, along with whether maybe the memory on your
system is maxed out (trigger high CPU load transfer data between RAM
and swap space).
There may be that too, but at this point I believe not. "top" and
"free", each time I look, show the swap space to be virtually unused.
The system as a whole is not overloaded, and the Tomcat-centric CPU
usage, although high in percentage, is finally a percentage of not
very much.
Let's just say that I am curious, apart from the fact that some Tomcat
applications which should answer quickly don't always.
So it's the thread dumps route for me then I guess ?
I was hoping someone would just point me to this nice "java-top"
Debian package...
First thing is to consider the big picture: Tomcat, as designed, does a
variety of things that consume CPU cycles - it just depends on how
you've got it configured. For example, is it setup to auto-deploy new
applications if a WAR file appears in the application root? If so, some
slice of it's behavior is checking for changes to the file system - an
expensive operation. You MUST understand the configuration you've
deployed, and any implications of performance robbing settings.
Secondly - one of the BETTER things to know is how to take and review
Java thread and memory (heap) dumps. Just behind that (or, sometimes in
front) is how to enable remote debugging - get that working and then you
can plug your favorite IDE into your webapp(s) for remote debugging. If
you know how to do this, you're going to be much better equipped to
diagnose a Tomcat/Java - regardless of the operating environment.
Third - (and IMO the BEST ) is you need to know is how (and when) to
log. Tomcat (as most things Apache) has quite a bit of logging
available. I don't know about the apps you are using, but you should
check logging facilities are available. You will want to use logging -
if you had no other tool excepting logging, you can likely pinpoint the
problem. (And obviously, whenever you enable more detailed logging,
you're going to incur performance hits...)
If you can couple logging with examining thread dumps, you'll be much
better to apply a factual "triage" on "what is it doing" (Tomcat vs.
webapps vs. other things) and in turn, help you decide if you have a
real issue.
Bottom line: Just because Tomcat is consuming system resource, it does
not mean something is "wrong". Think about this: If Tomcat wants a
slice of CPU time, and there's no contention, why would the system NOT
give it 100% of the CPU? When you "snapshot" system utilization with a
tool such as "top", it's not enough of a diagnostic tool to determine if
any given application (e.g., tomcat) is misbehaving. Especially, as
you've indicated, the system is not really in contention for resources...
Let me offer an analogy: If you were to just measure wind speed, is
that enough information to state there's a storm outside? Obviously,
it's not - you have to look at other factors, too.
Sorting out how to do these things is a worthwhile effort - try not to
shy away from it...
-- D Mansfield
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
