CentOs下查询一个进程下面的线程
在平时工作中,经常会听到应用程序的进程和线程的概念,那么它们两个之间究竟有什么关系或不同呢?
一、对比进程和线程
1)两者概念
进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位.
线程是指进程内的一个执行单元,也是进程内的可调度实体. 线程是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源.
2)两者关系
一个线程可以创建和撤销另一个线程;同一个进程中的多个线程之间可以并发执行.
相对进程而言,线程是一个更加接近于执行体的概念,它可以与同进程中的其他线程共享数据,但拥有自己的栈空间,拥有独立的执行序列。
3)两者区别
4)进程和线程的区别:
资源拥有:进程是资源分配和拥有的单位,同一个进程内的线程共享进程的资源
线程是处理器调度的基本单位,但进程不是.
进程和线程二者均可并发执行.
简而言之,一个程序至少有一个进程,一个进程至少有一个线程.
线程的划分尺度小于进程,使得多线程程序的并发性高。
另外,进程在执行过程中拥有独立的内存单元,而多个线程共享内存,从而极大地提高了程序的运行效率。
线程在执行过程中与进程还是有区别的。每个独立的线程有一个程序运行的入口、顺序执行序列和程序的出口。但是线程不能够独立执行,必须依存在应用程序中,由应用程序提供多个线程执行控制。
从逻辑角度来看,多线程的意义在于一个应用程序中,有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用,来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。
5)优缺点
线程和进程在使用上各有优缺点:
线程执行开销小,但不利于资源的管理和保护;而进程正相反。
线程适合于在SMP机器上(即对称多处理结构的简称,是指在一个计算机上汇集了一组处理器(多CPU),各CPU之间共享内存子系统以及总线结构)运行,而进程则可以跨机器迁移。
二、如何查看某个进程的线程数
有些时候需要确定进程内部当前运行了多少线程,查询方法如下:
1)通过pstree命令(根据pid)进行查询:
[root@xqsj_web2 ~]# ps -ef|grep java //查找进程pid(比如这里查找java(tomcat)进程的pid)
[root@xqsj_web2 ~]# pstree -p 19135
java(19135)─┬─{java}(19136)
├─{java}(19137)
.......
└─{java}(13578)
[root@xqsj_web2 ~]# pstree -p 19135|wc –l
或者使用top命令查看(可以查看到线程情况)
[root@xqsj_web2 ~]# top -Hp 19135 //下面结果中的Tasks 对应的47即是线程的个数
top - 14:05:55 up 391 days, 20:59, 1 user, load average: 0.00, 0.00, 0.00
Tasks: 47 total, 0 running, 47 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2%us, 0.1%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8058056k total, 7718656k used, 339400k free, 354216k buffers
Swap: 0k total, 0k used, 0k free, 4678160k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
19135 root 20 0 5339m 632m 5476 S 0.0 8.0 0:00.00 java
19136 root 20 0 5339m 632m 5476 S 0.0 8.0 0:00.84 java
2)根据ps命令直接查询:
[root@xqsj_web2 ~]# ps hH p 19135| wc –l
3)通过查看/proc/pid/status
proc伪文件系统,它驻留在/proc目录,这是最简单的方法来查看任何活动进程的线程数。/proc目录以可读文本文件形式输出,提供现有进程和系统硬件相关的信息如CPU、中断、内存、磁盘等等。
[root@xqsj_web2 ~]# cat /proc/19135/status
Name: java
State: S (sleeping)
Tgid: 19135
Pid: 19135
PPid: 1
TracerPid: 0
........
Threads: 47 //这里显示的是进程创建的总线程数。输出表明该进程有47个线程。
SigQ: 1/62793
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
.......
voluntary_ctxt_switches: 1
nonvoluntary_ctxt_switches: 1
或者,也可以在/proc/pid/task中简单的统计子目录的数量,如下所示:
root@xqsj_web2 ~]# ll /proc/19135/task
总用量 0
dr-xr-xr-x 6 root root 0 6月 14 17:57 11553
......
[root@xqsj_web2 ~]# ll /proc/19135/task|wc -l
48
这是因为,对于一个进程中创建的每个线程,在/proc/
比如某台服务器的CPU使用率飙升,通过top命令查看是gitlab程序占用的cpu比较大,"ps -ef|grep gitlab"发现有很多个gitlab程序,现在需要查询gitlab各个进程下的线程数情况。批量查询命令如下:
# for pid in $(ps -ef|grep -v grep|grep gitlab|awk '{print $2}');do echo ${pid} > /root/a.txt ;cat /proc/${pid}/status|grep Threads > /root/b.txt;paste /root/a.txt /root/b.txt;done|sort -k3 –rn
脚本解释:
1)for pid in $(ps -ef|grep -v grep|grep gitlab|awk '{print $2}')
定义${pid}变量为gitlab进程的pid号
2)echo ${pid} > /root/a.txt
将http进程的pid号都打印到/root/a.txt文件中
3)cat /proc/${pid}/status|grep Threads > /root/b.txt
将各个pid进程号下的线程信息打印到/root/b.txt文件中
4)paste /root/a.txt /root/b.txt
以列的形式展示a.txt和b/txt文件中的信息
5)sort -k3 -rn
-k3 表示以第三列进行排序
-rn 表示降序
通过top命令定位到cpu占用率较高的线程之后,继续使用jstack pid命令查看当前java进程的堆栈状态,这就用到jstack工具!
jstack是java虚拟机自带的一种堆栈跟踪工具。jstack用于打印出给定的java进程ID或core file或远程调试服务的Java堆栈信息。
jstack可以定位到线程堆栈,根据堆栈信息我们可以定位到具体代码,所以它在JVM性能调优中使用得非常多。
下面开始使用jstack对
[root@kevin ~]# jstack 31969 或者"jstack 31969 > jstack-31969" 打印出堆栈信息到一个文件中,方便后续查看
jstack命令生成的thread dump信息包含了JVM中所有存活的线程,为了分析指定线程,必须找出对应线程的调用栈,应该如何找?
在top命令中,已经获取到了占用cpu资源较高的线程pid,将该pid转成16进制的值,在thread dump中每个线程都有一个nid,找到对应的nid即可;隔段时间再执行一次stack命令获取thread dump,区分两份dump是否有差别,在nid=0x246c的线程调用栈中,发现该线程一直在执行JstackCase类第33行的calculate方法,得到这个信息,就可以检查对应的代码是否有问题。
排查Java内存问题,不要着急重启,保留现场。
free -g
df -h
ps -Lf pid | wc -l 来查看该Pid(进程)下的线程数
ps -Lf pid
netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 查看网络连接情况
线程dump:jstack -l 17121 | tee -a jstack.log
jstack -l 17121 > jstack.log
jstack -F -m -l 17121 >jstack.log
系统当前网络连接:ss -antp > ss.dump 2>&1
网络状态统计:netstat -s > netstat.dump 2>&1
sar输出当前的网络流量: sar -n DEV 1 2 > sar.dump 2>&1
进程资源:lsof -p $pid > lsof.dump
CPU 资源:
mpstat > mpstat.dump 2>&1
vmstat 1 3 > vmstat.dump 2>&1
sar -p ALL > sar.dump 2>&1
uptime > uptime.dump 2>&1
I/O资源:
iostat -x > iostat.dump 2>&1
内存资源:
free -h > free.dump 2>&1
其他全局:
ps -ef > ps.dump 2>&1
dmesg > dmesg.dump 2>&1
sysctl-a > sysctl.dump 2>&1
进程快照,最后的遗言 :jinfo $pid > jinfo.dump 2>&1
dump堆信息:
jstat -gcutil $pid > jinfo.dump 2>&1
jstat -gccapacity $pid > gccapacity.dump 2>&1
堆信息:
jmap $pid > jmap.dump 2>&1
jmap -heap $pid > jmap.dump 2>&1
jmap -histo $pid > jmap.dump 2>&1
jmap -dump:format=b,file=heap.bin $pid > /dev/null 2>&1
jvm执行栈:
jstack $pid > jstack.dump 2>&1
top -Hp $pid -b -n 1 -c > top.dump 2>&1
高级替补:
kill -3 $pid // stack并不能够运行,有很多原因。我们会尝试向进程发送kill -3信号,信号将会打印jstack的trace信息到日志文件中,是jstack的一个替补方案
gcore -o core.dump $pid
jhsdb jmap --exe ${jdk}java --core $DUMP_DIR/core --binaryheap
java9干掉jmap,取代它的是jhsdb:
jhsdb jmap --heap --pid 37340
jhsdb jmap --pid 37340
jhsdb jmap --histo --pid 37340
jhsdb jmap --binaryheap --pid 37340