Discussion:
Matching Java thread-ID to native Linux PID - Sun Java 1.5.x
(too old to reply)
Federico Cozzi
2010-11-22 13:07:11 UTC
Permalink
Hello,
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
2010-11-22 13:27:16 UTC
Permalink
Post by Federico Cozzi
Hello,
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
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
2010-11-22 14:44:05 UTC
Permalink
Post by Nigel Wade
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
2010-11-22 15:15:43 UTC
Permalink
Post by Federico Cozzi
Post by Nigel Wade
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.
Post by Federico Cozzi
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
2010-11-22 15:19:27 UTC
Permalink
Post by Federico Cozzi
Hello,
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
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
2010-11-22 20:15:43 UTC
Permalink
Post by Patricia Shanahan
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?
Federico Cozzi
2010-11-24 18:57:02 UTC
Permalink
Post by Patricia Shanahan
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?
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
2010-11-25 00:18:25 UTC
Permalink
Post by 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)
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
2010-11-25 00:33:06 UTC
Permalink
Post by Federico Cozzi
Post by markspace
Post by Patricia Shanahan
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?
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...
Have you looked at the Glassfish performance monitor?

Patricia
markspace
2010-11-25 01:03:31 UTC
Permalink
Post by Federico Cozzi
I hoped that matching java thread-IDs to native linux PIDs was
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?
s***@relianceco.com
2019-07-31 22:51:50 UTC
Permalink
Post by markspace
Post by Federico Cozzi
I hoped that matching java thread-IDs to native linux PIDs was
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?
9 years later.... I just confirmed that yes: "nid" in jcmd threaddump output from JDK 1.8 is indeed a hex encoded value of the Linux system PID on an Ubuntu server. We had a thread in the threaddump nid=760 and this correlated to Linux PID 1888 correctly.
Lew
2010-11-22 22:04:01 UTC
Permalink
Post by Patricia Shanahan
Post by 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
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
Loading...