I found "How to generate a Thread Dump"
<http://qa.netbeans.org/bugzilla/generating-thread-dumps.html>

I tested the StackTrace tool (the JNLP link near the bottom of that page),
and successfully grabbed a Java ThreadDump of a large Java-server-process
running on my Linux.
(Remember that your Tomcat-process is probably running with user-id root.
You therefore need to run your browser from root, so that the launched
JavaWS-application will run from root too, and hence has permission for
dumping the Tomcat-process.)
You should get the stack traces of all Tomcat threads. Watch out for busy
threads, i.e. the ones not idling in method Object.wait() or
Thread.sleep() .

On Apr 19, 9:32 am, tkonr...@gmx.at wrote:
...

How many users?  How slow?  Do you think you're hitting some
kind of I/O bottleneck (network / disk) or do you think it's more of
a performance problem in the way the Webapp is programmed?

No, you don't know the process ID of the thread.  You know the process
ID of the Tomcat process.

If you're running a non-antique Linux version there's no
one-to-one mapping between threads and processes. It
used to be like this in kernel 2.4 non-NPTL and older...

But it's not like that anymore.

Is it always slow or only occasionally?  Did you allocate a lot of
memory to Tomcat? (if so the GC kicking in may wreak havoc
and you'd be better to reconfigure the type of GC used)

Depending on why you're experiencing slowdown, you may
be better with a Java Webserver using multiplexing and NIO.

Many people are saying good things about Resin.

Of course the best Java Web server in the world won't
do much good if the slowness is due to a problem in
the way the Webapp itself is programmed.

If it was to me I'd first try to reproduce the problem
in a similar environment:  install same Linux + JDK +
Tomcat + Webapp then do some load-testing to try
to see what's going on.

The best, non-intrusive, way to do real-time profiling
on a production server would be to run DTrace on
(Open)Solaris...  But you'll have to wait some more
before that tool (and its Java probes) are ported to
Linux.

Good luck on finding the bottleneck and don't
hesitate to report once you solve the problem,

Alex

P.S: you may want to play with the memory settings
of the JVM and Tomcat's server.xml and see if it helps.

Processes are not the same thing as threads. By using top you have the
process ID of the process that contains multiple threads for Tomcat. If
you kill that process all the threads go away. You may need to look into
how OSes work when you have some spare time after fixing this problem.
Without the tool mentioned by Thomas you won't be able to determine the
individual Tomcat thread identifiers (if there are any to begin with)
unless you wanted to hack the kernel to provide that information.

No because you don't have further information to go on to determine
which thread within that process is the one you want. The process
contains multiple threads and the process ID is just a number that only
matches up with the process, hence the name.