Find the thread that occupies the most CPU resources in CentOS
1. monitor all threads in this process: top-ppid-H
2. Find the CPU-consuming THREAD: ps-mp pid-o THREAD, tid, time or ps-Lfp pid
3. You can also use the following command to find out the threads with high cpu usage:
Ps H-eo user, pid, ppid, tid, time, % cpu, cmd -- sort = % cpu
This command First specifies the parameter 'H' to display thread-related information. The format output contains: user, pid, ppid, tid, time, % cpu, cmd, then, sort by the % cpu field. In this way, you can find the thread that occupies the processor.
Use ps Hh-eo pid, tid, pcpu | sort-nk3 | tail to get the process and thread numbers, and then jump to 3.
Check which process thread occupies too high cpu; top/ps-aux, get process number
Determine which thread occupies too much cpu and enter the process number directory:/proc/pid/task,
Run: grep SleepAVG **/status | sort-k2, 2 | head to determine the thread number with high cpu usage.
Use the kill-3 pid to print the thread Stack
In Linux, the top tool displays the average cpu usage (user, nice, system, idle, iowait, irq, softirq, etc.), showing the utilization of each cpu. However, the cpu usage of each thread cannot be displayed. This may occur when the user or system is high in the total cpu usage, but the cpu usage of the process is sorted, there is no user or system corresponding to the process.
Proc file system
The/proc file system is a pseudo file system, which only exists in the memory and does not occupy the external storage space. It provides a communication interface between the kernel and processes in the form of a file system. Users and applications can obtain system information through/proc and change certain kernel parameters. Because system information, such as processes, is dynamically changed, when users or applications read files in the/proc directory, the proc file system dynamically reads the required information from the system kernel and submits it.
The/proc directory contains some directories named by numbers, which are process directories. Each process currently running in the system corresponds to a directory/proc/pid named by process under/proc. They are interfaces for reading process information. In addition, the/proc/pid directory contains a task directory in Linux2.6.0-test6 or later versions, the/proc/pid/task directory also contains the/proc/pid/task/tid directory named after the thread Number of the process. They are interfaces for reading thread information.
/Proc/cpuinfo File
This file contains information about the cpu (model, cache size, etc ).
[Zhengangen @ buick ~] $ Cat/proc/cpuinfo
Processor: 0
Vendor_id: GenuineIntel
Cpu family: 15
Model: 4
Model name: Intel (R) Xeon (TM) CPU 3.00 GHz
Stepping: 10
Cpu MHz: 3001.177
Cache size: 2048 KB
Physical id: 0
Siblings: 2
Core id: 0
Cpu cores: 1
Fdiv_bug: no
Hlt_bug: no
F00f_bug: no
Coma_bug: no
Fpu: yes
Fpu_exception: yes
Cpuid level: 5
Wp: yes
Flags: fpu vme de psetsc msr pae mce cx8 apic mtrr pge mca cmov pat limit 36 clflush dts acpi mmx fxsrsse sse2 ss ht tm pbe lm pni monitor ds_cpl cid xtpr
Bogomips: 6004.52
Note: The following describes only the parameters that are useful for Cpu usage calculation.
Parameter description
A physical identifier of processor (0) cpu
Conclusion 1: This file can be used to count the number of cpu logic (including multi-core and hyper-threading) based on the number of processor occurrences ).
/Proc/stat File
This file contains information about all CPU activities. All values in this file are accumulated from the start of the system to the current time. In different kernel versions, the file format may be inconsistent. The following example describes the meaning of fields in the file.
Instance data: 2.6.24-24
Fjzag @ fjzag-desktop :~ $ Cat/proc/stat
Cpu 38082 627 27594 89390812256 581 0 0
Cpu022880 472 16855 430287 10617 576 661 0 0
Cpu115202 154 10739 463620 1639 4 234 0 0
Intraday 53 222 2686 47302 0 1 1 0 5 0 3 0 0 0 0 0 34194 29775 0 5019 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Ctxt1434984
Btime1252028243
Processes8113
Procs_running1
Procs_blocked0
The value in the first row indicates the total CPU usage, so we only need to use the number in the first row. The following table describes the meanings of values in the first row:
Parameter Parsing (unit: jiffies)
(Jiffies is a global variable in the kernel. It is used to record the number of beats generated after the system starts. in linux, a cycle is generally considered as the minimum time slice for operating system process scheduling, different linux kernels may have different values, usually between 1 ms and 10 ms)
User (38082) indicates the running time of the user State from the system start to the current time. The nice value is not included in the process.
Nice (627) indicates the CPU time occupied by processes whose nice value is negative from system startup to current time.
System (27594) runs in the core State from the start of the system to the current time.
Idle (893908) accumulates from the system startup to the current time, And iowait (12256) accumulates from the system startup to the current time, except for the IO wait time, IO wait time (since 2.5.41)
Irq (581) Hardware interruption time (since 2.6.0-test4)
Softirq (895) accumulates from system startup to current time, Soft Interrupt time (since2.6.0-test4) stealstolen (0) which is the time spent in otheroperating systems when running in a receivalized environment (since 2.6.11)
Guest (0) whichis the time spent running a virtualCPU for guest operating systems under the control ofthe Linux kernel (since 2.6.24)
Conclusion 2: total cpu time totalCpuTime = user + nice + system + idle + iowait + irq + softirq + stealstolen + guest
/Proc/<pid>/stat File
This file contains information about all activities of a process. All values in this file are accumulated from the start of the system.
To the current time. The following describes the meaning of each field in the file through instance data.
[Zhengangen @ buick ~] # Cat/proc/6873/stat
6873 (. out) R 6723 6873 6723 34819 6873 8388608 77 0 0 41958 31 0 0 25 0 0 3 05882654 56 1409024 4294967295 134512640 134513720 0 3215579040 0 0 0 0 00 0 0 17 0 0 0 0 0 0
Note: The following only describes the useful parameters for Cpu usage calculation.
Parameter description
Pid = 6873 process no.
Utime = 1587 time when the task runs in user mode, in jiffies
Stime = 41958 time when the task runs in the core State, in jiffies
Cutime = 0 time when all dead threads run in the user State, in jiffies
Cstime = 0 all dead time in the core State, in jiffies
Conclusion 3: The total Cpu time of the Process processCpuTime = utime + stime + cutime + cstime. This value includes the cpu time of all its threads.
/Proc/<pid>/task/<tid>/stat File
This file contains information about all activities of a process. All values in this file are accumulated from the start of the system to the current time. The content format of the file and the meaning of each field are the same as that of the/proc/<pid>/stat file.
Note that the tid field in this file does not represent the process number, but the Lightweight Process (lwp) in linux, which we usually call a thread.
Conclusion 4: thread Cpu time threadCpuTime = utime + stime
Common ps commands on cpu usage of processes in the system
You can run the ps command to view the Cpu usage of related processes in the system. The following explains the cpu usage in the ps command output in the linux man document:
CPU usage is currentlyexpressed as the percentage of time spent running during the entire lifetime ofa process. this is not ideal, and it does not conform to the standards that psotherwise conforms. the CPU usage is unlikely to add up to exactly 100%.
% Cpu utilization of the process in "##. # "format. it is the CPU time used divided by the timethe process has been running (cputime/realtime ratio), expressed as apercentage. it will not add up to 100% unless you are lucky.
Conclusion 5: The cpu usage calculated by the ps command is equal to the average value when the process is started. As the running time of the process increases, the value tends to be gentle.
Top Command
You can use the top command to view the real-time information (cpu usage, etc.) of related processes in the system ). The following is an explanation of the process cpu usage in the top command output in the man document.
# C -- Last used CPU (SMP) Anumber representing the last used processor. in a true SMPenvironment this willlikely change frequently sincethe kernel intentionally usesweak affinity. also, the very act ofrunning top may break this weak affinity and cause more processes to changeCPUs more often (because of the extra demand for cputime ).
% CPU -- CPUusage The task's share ofthe elapsed CPU time since the last screen update, expressed as a percent-ageof total CPU time. in a true SMP environment, if Irix mode is Off, top will operate in Solaris modewhere a task's cpu usage will be divided by the total number of CPUs.
Conclusion 6: The cpu used by a thread during its running may change.
Conclusion 7: In multi-core scenarios, the cpu usage output by the top command is calculated based on the number of CPUs x 100%.
Basic Idea of calculating Cpu usage in Single-core scenarios
Obtain the total number of files by reading/proc/stat,/proc/<pid>/stat,/proc/<pid>/task/<tid>/stat, And/proc/cpuinfo. cpu time, Cpu time of the Process, Cpu time of the thread, and number of CPUs, then, a certain number of algorithms are used to calculate the Cpu usage. (Two Cpu snapshots and process snapshots are sampled to calculate the Cpu usage of the process ).
Total Cpu usage calculation method:
1. Two Cpu snapshots with short enough time intervals are recorded as t1 and t2 respectively. The t1 and t2 structures are as follows:
(User, nice, system, idle, iowait, irq, softirq, stealstolen, guest) 9 tuples;
2. Calculate the total Cpu time slice totalCpuTime
A) sum all cpu usage for the first time and obtain s1;
B) sum all cpu usage for the second time to obtain s2;
C) s2-s1 obtain all the time slices in this interval, that is, totalCpuTime = j2-j1;
3. Calculate the idle time idle
Idle corresponds to the data in the fourth column. Use the fourth column of the second time-the fourth column of the first time.
Idle = fourth column of the second operation-fourth column of the first operation
6. Calculate cpu usage
Pcpu = 100 * (total-idle)/total
Calculation Method for Cpu usage of a process:
1. Sample two cpu snapshots and process snapshots at a short enough interval,
A) Each cpu snapshot is nine tuples (user, nice, system, idle, iowait, irq, softirq, stealstolen, and guest;
B) each process snapshot is a 4-tuple (utime, stime, cutime, cstime;
2. Calculate the total cpu time and the cpu time of the process based on conclusions 2 and 3, respectively, as: totalCpuTime1, totalCpuTime2, processCpuTime1, processCpuTime2
3. calculate the cpu usage of the process (pcpu = 100 * (processCpuTime2-processCpuTime1)/(totalCpuTime2-totalCpuTime1) (calculated by 100%, if it is multi-core, you need to multiply the number of CPUs );
Lab data
Experiment 1: monitor the cpu usage of an out-of-the-loop process.
Note: The data on the left is obtained based on the above algorithm. The sampling interval is the same as the interval at which the top Command refreshes the screen.
Cpu usage calculated based on the preceding Method
Obtained through the top Command
99.50083
98.333336
98.0
98.83138
99.0
99.0
99.83361
98.83527
98.4975
Pid user pr ni virt res shr s % CPU % mem time + COMMAND
7639 fjzag 20 0 206 m 10 m 7136 S 99 2.2. 74 java
7639 fjzag 20 0 206 m 10 m 7136 S 99 2.2. 71 java
7639 fjzag 20 0 206 m 10 m 7136 S 99 2.2. 67 java
7639 fjzag 20 0 206 m 10 m 7136 S 99 2.2. 63 java
7639 fjzag 20 0 206 m 10 m 7136 S 98 2.2. 59 java
7639 fjzag 20 0 206 m 10 m 7136 S 99 2.2. 55 java
7639 fjzag 20 0 206 m 10 m 7136 S 100. 55 java
7639 fjzag 20 0 206 m 10 m 7136 S 100 2.2. 54 java
7639 fjzag 20 0 206 m 10 m 7136 S 99 2.2. 52 java
7639 fjzag 20 0 206 m 10 m 7136 S 98 2.2. 46 java
Experiment 2: monitor the cpu usage of the jconsole process.
Note: The data on the left is obtained based on the above algorithm. The sampling interval is the same as the interval at which the top Command refreshes the screen.
Cpu usage calculated based on the preceding Method
Obtained through the top Command
8.681135
12.0
10.350584
7.6539097
7.6539097
5.0
13.021703
11.0
8.666667
Pid user pr ni virt res shr s % CPU % mem time + COMMAND
7753 fjzag 20 0 252 m 72 m 22 m S 10 14.4. 70 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 12 14.4. 07 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 11 14.4. 39 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 7 14.4. 61 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 7 14.4. 83 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 5 14.4. 97 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 14 14.4. 38 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 10 14.4. 68 jconsole
7753 fjzag 20 0 252 m 72 m 22 m S 9 14.5. 96 jconsole
Calculation Method for Cpu usage of a thread:
1. Sample two cpu snapshots and thread snapshots that are separated by a short time,
A) Each cpu snapshot is nine tuples (user, nice, system, idle, iowait, irq, softirq, stealsteron, and guest;
B) Each thread snapshot is a 2-tuple of (utime, stime;
2. Calculate the total cpu time and the cpu time of the thread based on conclusions 2 and 4 respectively, respectively, as: totalCpuTime1, totalCpuTime2, threadCpuTime1, and threadCpuTime2
3. calculate the cpu usage of this thread (pcpu = 100 * (threadCpuTime2-threadCpuTime1)/(totalCpuTime2-totalCpuTime1) (calculated by 100%, if it is a multi-core, you need to multiply the number of CPUs );
Lab data
Experiment 1: monitor the cpu usage of an endless thread.
Note: The data on the left is obtained based on the above algorithm. The sampling interval is the same as the interval at which the top Command refreshes the screen.
Cpu usage calculated based on the preceding Method
Obtained through the top Command
98.83138
97.00997
96.98997
97.49583
98.169716
96.8386
97.333336
93.82304
98.66667
Pid user pr ni virt res shr s % CPU % mem time + COMMAND
7649 fjzag 20 0 206 m 10 m 7136 R 97 2.2. 94 java
7649 fjzag 20 0 206 m 10 m 7136 R 97 2.2. 86 java
7649 fjzag 20 0 206 m 10 m 7136 R 97 2.2. 76 java
7649 fjzag 20 0 206 m 10 m 7136 R 99 2.2. 72 java
7649 fjzag 20 0 206 m 10 m 7136 R 98 2.2. 65 java
7649 fjzag 20 0 206 m 10 m 7136 R 96 2.2. 53 java
7649 fjzag 20 0 206 m 10 m 7136 R 98 2.2. 47 java
7649 fjzag 20 0 206 m 10 m 7136 R 96 2.2. 34 java
7649 fjzag 20 0 206 m 10 m 7136 R 97 2.2. 25 java
Experiment 2: monitor the cpu usage of a thread in the jconsole program.
Note: The data on the left is obtained based on the above algorithm. The sampling interval is the same as the interval at which the top Command refreshes the screen.
Cpu usage calculated based on the preceding Method
Obtained through the top Command
1.3400335
6.644518
1.3333334
0.6677796
0.6666667
1.3333334
1.3333334
Pid user pr ni virt res shr s % CPU % mem time + COMMAND
7755 fjzag 20 0 251 m 72 m 22 m S 1 14.4. 92 jconsole
7755 fjzag 20 0 251 m 72 m 22 m S 7 14.4. 12 jconsole
7755 fjzag 20 0 251 m 72 m 22 m S 2 14.4. 18 jconsole
7755 fjzag 20 0 251 m 72 m 22 m S 0 14.4. 18 jconsole
7755 fjzag 20 0 251 m 72 m 22 m S 1 14.4. 20 jconsole
7755 fjzag 20 0 251 m 72 m 22 m S 1 14.4. 24 jconsole
7755 fjzag 20 0 251 m 72 m 22 m S 1 14.4. 28 jconsole
Cpu usage calculation in multi-core scenarios
The following experiment shows that the cpu usage of a process in multiple cores is calculated based on the number of CPUs x 100%.
Tutorial 1:
In a dual-core experiment, the first group of data is to view the details of each thread in a process with process number 9140 through the ps-eLo pid, lwp, pcpu | grep 9140 command. The second group of data is to view the cpu usage of the process with process number 9140 through the ps command.
Data 1:
Pid lwp % cpu
914091400.0
914091410.0
914091420.0
914091430.0
914091440.0
914091490.0
914091500.0
914091510.0
914091520.1
9140915396.6 this thread is an empty Loop
9140915495.9 this thread is an empty Loop
The two threads marked in red are all background threads.
Data 2:
Pid % cpu
9140193
Tutorial 2 Description:
In a single-core experiment, the first group of data is to view the details of each thread in a process with process number 6137 through the ps-eLo pid, lwp, pcpu | grep 6137 command. The second group of data is to view the cpu usage of the process with process number 6137 through the ps command.
Data 1:
Pid lwp % cpu
61376137 0.0
61376138 0.1
61376143 0.0
61376144 0.0
61376145 0.0
61376146 0.0
61376147 0.0
61376148 0.0
61376149 0.0
61376150 46.9 empty loop thread
61376151 46.9 empty loop thread
The two threads marked in red are all background threads.
Data 2
Pid % cpu
6137 92.9
Main problems:
1. Different kernel versions/proc/stat file formats are not consistent. The cpu usage of the first behavior in the/proc/stat file.
Each version has four fields: user, nice, system, and idle.
2.5.41 new field: iowait
2.6.0-test4 new fields: irq and softirq
2.6.11 new field: stealstolen: which is thetime spent in other operating
Systems whenrunning in a virtualized environment
2.6.24 new field: guest: whichis the time spent running a virtualCPU for guest operating systems under the control ofthe Linux kernel
2. The/proc/pid/task directory is available only after Linux 2.6.0-test6.
3. When the cpu usage is negative, the current solution is to calculate the cpu usage continuously until it is not negative.
4. Some threads have a short life cycle and may have died during our sampling.
Cause Analysis and Solution steps of excessive cpu resources used by the php-cgi process
Server Environment: redhat linux 5.5, nginx, phpfastcgi
In this environment, php-cgi generally runs very stably, but it has encountered that php-cgi occupies too many cpu resources, resulting in slow server response, the reasons why the php-cgi process occupies too many cpu resources are as follows:
1. some php extensions and php versions are compatible. Practice has proved that eAccelerater is compatible with some php versions. When the php-cgi process is started, it runs for more than 10 minutes, which is extremely slow, however, static resources are accessed quickly, and the server load is normal (indicating that nginx is not a problem, but the php-cgi process is a problem). The solution is from php. disable the eAccelerater module in ini and restart the php-cgi process.
2. There may be an endless loop in the program, resulting in extremely high server load (using the top command to view the load as high as 100 +), you need to find the specific problem program using the Linux proc Virtual File System
3. the php program improperly uses the session, which occurs in the open-source Weibo notebook dog program. The actual performance is that there are a small number of php-cgi processes (no more than 10) with a cpu usage rate of more than 98%, the server load is between 4-8. To solve this problem, you still need to use the Linux proc file system to find out the cause.
4. Operations in the program that are too time-consuming and impossible to complete (or program problems), such as discuz x 1.5's attachment download function: definitions in source/module/forum/forum_attachement.php
Function getremotefile ($ file ){
Global $ _ G;
@ Set_time_limit (0 );
If (! @ Readfile ($ _ G ['setting'] ['ftp '] ['attachurl']. 'Forum/'. $ file )){
$ Ftp = ftpcmd ('object ');
$ Tmpfile = @ tempnam ($ _ G ['setting'] ['attachdir'], '');
If ($ ftp-> ftp_get ($ tmpfile, 'Forum/'. $ file, FTP_BINARY )){
@ Readfile ($ tmpfile );
@ Unlink ($ tmpfile );
} Else {
@ Unlink ($ tmpfile );
Return FALSE;
}
}
Return TRUE;
}
No preliminary check is performed on the input parameters, and the setting never times out. If you use readfile to read a large file at a time, the following problems may occur:
A. excessive time consumption for reading remote attachments via http
B. How can I report errors in a timely manner when FTP cannot be connected?
C. readfile is a one-time read of files loaded into the memory and output. When the file is too large, the memory consumption is astonishing.
According to the experiment, we found that using readfile for one-time reading will significantly increase the memory consumption, but the CPU utilization will decrease a lot. If the multipart read method is used, the memory consumption decreases slightly, while the CPU usage increases significantly.
A better solution to the bug of discuz x 1.5 is to reset the remote attachment parameters in the background.
The Troubleshooting steps are as follows:
1. Obtain the pid (process id) of the php-cgi process that occupies too many cpu resources. Use the top command, for example:
After that, we found that the cpu usage of two php-cgi processes was too high, and the pid was 10059,11570, which was generally caused by insufficient program optimization. How to locate the problematic php program location?
2. Find the files used by the Process
/Proc/the file system is stored in the memory, mainly to save the status of the system, key configurations, and so on. The/proc/directory contains many digital directories, which are process-related information, such, let's see what files are being used by process 10059?
Obviously, the/home/tmp/sess _ * file is used, which is obviously a PHP session file. We can view the content of this session file as follows: view_time | 123333312412
We can already suspect that the php program has written a session item called view_time, so the remaining event is to check all php files containing view_time, then modify it (for example, use a COOKIE). To tell the truth, this view_time is not sensitive data and only records the last access time of the user. It is really unnecessary to use a session with a huge cost, instead, use a cookie.
3. Find the problematic program and modify it.
Use vi to edit the following shell program (assuming that the website program is in the/www directory)
#! /Bin/bash
Find/www/-name "*. php"> list.txt
F = 'cat./list.txt'
For n in $ f
Do
R = 'egrep 'view _ time' $ N'
If [! "$ R" = ""]; then
Echo $ n
Fi
Done
Run this shell program and output a file containing view_time. the problem caused by the system is in the modules/topic. mod. class file.
Http://blog.csdn.net/turkeyzhou/article/details/6709953
Http://www.cnblogs.com/cute/archive/2011/04/20/2022280.html
Recently, I used the top command to check that the CPU usage of my local database (4-core 8-thread) exceeded 200% in the system. I was surprised to find out the relevant information, clarify the problem.
First, analyze the CPU Load
Load average: 0.09, 0.05, 0.01
The average Load is 1 minute, 5 minutes, and 15 minutes respectively.
How can I understand this? It's like a road with N lanes. If N processes enter the lanes, one person will be there, and one more car will not be able to occupy the lanes, wait for a car to exit.
In the CPU, it can be understood as the number of tasks that the CPU can process in parallel, that is, "Number of CPUs * Number of cores". If the CPU Load = number of CPUs * Number of cores, that is, the CPU is fully loaded, A little more, there may be problems. If a task cannot be allocated to a processor in time, it is better to be less than the number of CPU cores x number of cores * 0.7 to ensure performance.
To view the number of CPU cores, run: grep 'model name'/proc/cpuinfo.
Which of the following is the average value? If the average number of cores is greater than the number of CPUs * in one minute, you don't have to worry about it. If the average number is also 5 minutes, you have to be cautious. The average number is also 15 minutes, so you have to analyze what went wrong, prevent against unexpected events
The CPU usage exceeds 100%, which is similar. The top command should sum up the CPU usage of each core to calculate a sum. Therefore, the CPU usage of multiple cores will exceed 100%.
In addition, Context Switch Rate is a very noteworthy value, because the price for inter-thread switching is also very high.
Reference a formula: Context Switch Rate = Interrupt Rate + TPS * N
For a multi-threaded program, I think it is necessary to prepare a control thread to schedule tasks, so that the threads are too high concurrency, resulting in resource contention and thread switching leading to performance problems, it is best to control the number of concurrent threads, which is basically equal to the total number of CPU cores. reduce this N to achieve better processor performance.
Java System Performance Analysis command 1. cpu Analysis
Top, pidstat (sysstat)
Pid-p PID-t 1 10
Vmstat 1 CPU context switch, running queue, Utilization
Ps Hh-eo tid
Pcpu view the CPU consumption of a specific thread
Sar to view cpu consumption information in a certain world and history
View java thread Information
Jstack pid | grep 'nid = 0x9999'
2. high consumption of cs sy
High context switching performance, jstack-l pid, view on object monitor
3. io consumption
Pidstat-d-t-p pid 1 100
Iostat
4. Network io consumption
Cat/proc/interruptes
Sar-n FULL 1 2
Tcpdump