Matching Java thread-ID to native Linux PID - Sun Java 1.5.x
Federico Cozzi
I am running a J2EE app on Linux using Sun Java 1.5.x.
Is there a way to match Java thread-ID to native Linux PID?
According to top ("top -H") there are some Java threads running at
100% CPU and this is wrong.
I would like to debug this and the first step is understanding which
threads I should investigate.
(BTW, what is the second step? getting a stack-trace?)
This is a production environment, therefore my analysis should not
interfere with the running app
Thanks,
Federico
Nigel Wade
ps -Lef
will show every LWP along with the associated PID and PPID.
Then it's just a matter of finding the right line in the many, many
lines of output. You can help reduce the output with suitable use of the
usual culprits such as 'grep' and 'awk'.
--
Nigel Wade
Federico Cozzi
> ps -Lef
> will show every LWP along with the associated PID and PPID.
This outputs only Process ID (and Parent Process ID), which is an OS-
level ID.
I need to correlate this output to Java Thread-ID, which is a JVM-
level ID (starts from 1 when the JVM is started) and is what most Java
tools use. Under Java a thread has both a thread-name and a thread-ID;
if the JVM uses native threads (like Sun Java 1.5 on Linux) each Java
Thread is mapped to a Linux LWP, but IDs are different.
Bye,
Federico
Nigel Wade
> On 22 Nov, 14:27, Nigel Wade <nmw-n...@ion.le.ac.uk> wrote:
>> ps -Lef
>> will show every LWP along with the associated PID and PPID.
>
> This outputs only Process ID (and Parent Process ID), which is an OS-
> level ID.
It outputs the PID, the PPID and the LWP id. The LWP id is what 'top -H'
shows in the PID field, which is what you need to map a thread to the
actual PID.
>
> I need to correlate this output to Java Thread-ID, which is a JVM-
> level ID (starts from 1 when the JVM is started) and is what most Java
> tools use. Under Java a thread has both a thread-name and a thread-ID;
> if the JVM uses native threads (like Sun Java 1.5 on Linux) each Java
> Thread is mapped to a Linux LWP, but IDs are different.
It appears I misunderstood your post. I thought you wanted to identify
which Java process was running the the theads in question so you could
attach a Java debugger to the correct process. I'm sorry, I have no idea
how Java thread id's relate to the LWP id.
--
Nigel Wade
Patricia Shanahan
My first try at this would not involve the mapping at all. I would run
the program under Eclipse in debug mode, bring it to as idle a state as
possible, and then monitor the debug display to see which threads are
running all the time. You would immediately be able to pause the run and
check what each thread is doing.
Patricia
markspace
> My first try at this would not involve the mapping at all. I would run
> the program under Eclipse in debug mode,
Patricia makes a good point. The first step in most debugging
investigations is to reproduce the problem. Poking at the live server
is likely to be difficult at best, with the restrictions placed on you
to not actually disturb the production environment and what not.
Playing with threads and debugging can vary with the actual container
used, which you didn't mention. Are you using JBoss? Tomcat?
Websphere? What version?
Lew
>> I am running a J2EE app on Linux using Sun Java 1.5.x.
>> Is there a way to match Java thread-ID to native Linux PID?
>> According to top ("top -H") there are some Java threads running at
>> 100% CPU and this is wrong.
>> I would like to debug this and the first step is understanding which
>> threads I should investigate.
>> (BTW, what is the second step? getting a stack-trace?)
>> This is a production environment, therefore my analysis should not
>> interfere with the running app
>
Patricia Shanahan wrote:
> My first try at this would not involve the mapping at all. I would run
> the program under Eclipse in debug mode, bring it to as idle a state as
> possible, and then monitor the debug display to see which threads are
> running all the time. You would immediately be able to pause the run and
> check what each thread is doing.
>
Other IDEs work similarly.
--
Lew
Federico Cozzi
We are using Glassfish 2.1.1
I can't reproduce it in debugging environment, since it happens very
rarely (once every two months or so) after a lot of load on the
application server (it's a production server after all)
It could even be that it's not an "application" thread (i.e. a thread
serving web requests) but a thread which is internal to the
application server itself.
I hoped that matching java thread-IDs to native linux PIDs was
easier...
Bye,
Federico
markspace
> We are using Glassfish 2.1.1
> I can't reproduce it in debugging environment, since it happens very
> rarely (once every two months or so) after a lot of load on the
> application server (it's a production server after all)
We get a lot of different levels of experience here; it's a knee-jerk
reaction I think for folks to start with remedial advice.
Does this link help you? It's almost the holidays here and I don't have
time to check it out personally.
<http://docs.sun.com/app/docs/doc/820-4339/6nfqftsnj?l=en&a=view>
P.S. I searched with Google for "glassfish thread dump"
Patricia Shanahan
Have you looked at the Glassfish performance monitor?
Patricia
markspace
> easier...
Just found this poking around late today. It describes how to match a
Solaris thread to a Java thread. I wonder if other 'nix are similar?
<http://www.camelrichard.org/matching-java-thread-nid-tid-solaris-10-threads-using-pstack>
It seems based on the "nid" of the Java thread dump. nid = native ID
perhaps?
