MapReduce's thread dump gets the bitterness

====2016/5/20:

The thread stack of the server that requires Mr to be intercepted for Mr Performance tuning (thread Dump)

Comrade-in-arms introduced the method is this:

①, using the PS command "PS-EF | grep java "Filters out all Java processes (after all, MapReduce is running in the JVM)

②, the PID (process ID) of the running process for which Mr is found from the Java process

③, use kill-3 <pid> command to get thread Dump. Gets the standard output after the log stdout .

Colleague's introduction or more detailed, in accordance with this method to try a bit, it is really possible to obtain the thread Dump. (Can prove that it's not a pit mate.)

However, there are two problems in the process of actual operation, which brings me a lot of trouble:

Problem ①, Java process too much, with the naked eye to find Mr is too difficult . Often without waiting to find out, the process is over.

Cause kill-3 <pid>, you will be prompted with the following information.

Problem ②, even if the PID of the Mr Process is found, using the kill-3 command is not always a good way to get thread Dump.

※ Use Ps-ef | grep java results such as: Look at this figure is more distressed own eyes.

In response to the problem ①, the afternoon was improved by grep, instead of using the Java keyword, use Mr's job ID to grep.

Jobid can be obtained by two ways:

Route 1:shell Command Line

When you use the Hadoop jar <jar name > < class name > Run a jar package, the job is accepted and starts running with a jobid assigned to it, which is indicated on the console.

Route 2:web Page

All jobs are represented on the Web page, where the second half of the ID of the application Manager for the first column is the same as Jobid, which is also possible with this.

Then use ps-ef | grep <job id> to find all the processes related to this job. As shown in the following:

After a little trial, it was a lot easier to find Mr's process. It is very gratifying ...

But the question above ②,threaddump not every success problem still bothers me. And after the afternoon, since No 1 times can successfully obtain the thread Dump.

====2016/5/21

Today is Saturday, to push off some of the life of the appointment (the normal of hardship code farmers), decisively come over to work overtime.

Walking on the road, full of head is the problem ② things, there is no clue. Later, I think of yesterday's leadership casually said: is not your kill process is not correct?

The feeling is very reasonable, why not try it? Can't wait to come to the company, turn on the computer, try to kill the different processes of Mr.

As a result, the day the dog, unexpectedly really is some process can not get thread Dump, and some process will be. Sad to urge at the same time, see a ray of light is also more happy.

So, the question is, what is the difference between these processes, and what process can get thread dump?

After a survey, the following conclusions are obtained:

--------

The system will correlate several numbers when running each process, namely PID, Ppid, UID, Euid.

The PID of the process is automatically assigned by the system when the process is run, and is used to uniquely identify an integer for this process. The ppid of the process is the PID of the process's parent process

--------

This means that there is a parent-child relationship between processes. Experimental results show that thread Dump can only be obtained by using kill-3 on the final sub-PID.

The procedure is as follows: ※ The blue part is the child process, the red is the parent process.

The contents of the stdout are as follows.

See the following content, a kind of want to cry feeling .....

= = Summary

①, using the PS command to view the PID of the process, you can use the GREP keyword. To reduce the scope

② can use kill-3 <pid> to send messages to intercept thread dump.

③, kill-3 must be used for the final child process. Remember, remember.

MapReduce's thread dump gets the bitterness