当前位置:   article > 正文

如何查java当前负载_linux进程和线程排查 · 记一次JVM CPU高负载的排查办法

ps -ef|grep java

前言

通过本文,你将学会:

1、linux上进程及进程中线程排查的基本方法,如查看进程中的线程数

此文中的线程一般指轻量级进程。

查看所有进程信息 top -H

加上-H这个选项启动top,top一行显示一个线程(指的是(轻量级)进程? )。否则,它一行显示一个进程。

先输入top -p 20378 只显示该进程的变化情况 ,但是在按H(shift + h)后,会显示threads的信息,但是总的CPU占用之和远小于没按H之前的占用之和。

轻量级进程(LWP)

轻量级进程(LWP)是一种实现多任务的方法。与普通进程相比,LWP与其他进程共享所有(或大部分)它的逻辑地址空间和系统资源;与线程相比,LWP有它自己的进程标识符,优先级,状态,以及栈和局部存储区,并和其他进程有着父子关系。

后文中的LWP粗略认为是线程。LWP的一个重要作用是提供了一个用户级线程实现的中间系统。LWP可以通过系统调用获得内核提供的服务,因此,当一个用户级线程运行时,只需要将它连接到一个LWP上便可以具有内核支持线程的所有属性。

实验观察

某个时刻下的截图

97909715be4b4b9440a5a769d6d5d50c.png

个别时间下出现CPU占用1000%,出现次数几乎可以忽略。

操作总结

一般通过top -H定位想要具体分析的Java进程对应的PID,此处为22564。

htop

install htop 一个比top更强大的命令,支持点击 %CPU %MEM后进行排序

查看进程下的线程信息

两种命令

ps -Lf pid 查看对应进程下的线程信息

pstree -p 22564 通过进程PID查看进程下线程的PID

上面两个命令的缺点: 没有线程占用资源的信息

ps -Lf pid

通过ps -Lf pid 查看对应进程下的线程信息 ,查到pid 22564下有1个进程(自身)+48个线程,如下图所示:

9988c2932e4e8db9a4986994b66d4721.png

6ec20c839d7a50d6379de880887f786f.png

上图是截图左半部分

309b4b667dd608cdad749c40d5dfd714.png

上图是截图右半部分

pstree -p 22564

pstree -p 22564 通过进程PID查看进程下线程的PID

c11e8e8fdea456611b3a33814a78d3b5.png

ps命令详解

ps –e | grep java

ps命令可以查看进程状态,如执行如下命令:

ps –e | grep java

结果如下图:

format,png

可以看到,只打印了一个进程的信息;27989是线程id,java是指执行的java命令。这是因为启动一个tomcat,内部所有的工作都在这一个进程里完成,包括主线程、垃圾回收线程、Acceptor线程、请求处理线程等等。

ps –o nlwp 27989

通过ps –o nlwp 27989命令,可以看到该进程内有多少个线程;其中,nlwp含义是number of light-weight process。

format,png

获取真正在running的线程

可以看到,该进程内部有73个线程;但是73并没有排除处于idle状态的线程。要想获得真正在running的线程数量,可以通过以下语句完成:

ps -eLo pid ,stat | grep 27989 | grep running | wc -l

其中ps -eLo pid ,stat可以找出所有线程,并打印其所在的进程号和线程当前的状态;两个grep命令分别筛选进程号和线程状态;wc统计个数。其中,ps -eLo pid ,stat | grep 27989输出的结果如下:

format,png

图中只截图了部分结果;Sl表示大多数线程都处于空闲状态。

JVM CPU高负载的排查办法

今天线上一个java进程cpu负载100%。按以下步骤查出原因。

1.执行top -c命令,找到cpu最高的进程的id

2.执行top -H -p pid,这个命令就能显示刚刚找到的进程的所有线程的资源消耗情况。找到CPU负载高的线程pid 8627, 把这个数字转换成16进制,21B3(10进制转16进制,用linux命令: printf %x 8627)。

3.执行jstack -l pid,拿到进程的线程dump文件。这个命令会打出这个进程的所有线程的运行堆栈。

4.用记事本打开这个文件,搜索“21B3”,就是搜一下16进制显示的线程id。搜到后,下面的堆栈就是这个线程打出来的。排查问题从这里深入。

今天最后排查出来的结果是“VM THREAD”把进程的资源耗尽。那只能说明是jvm在耗cpu。很容易想到是疯狂的GC,按关键字 “overhead” 搜一下系统日志, 发现 “java.lang.OutOfMemoryError: GC overhead limit exceeded”日志。问题明了了。jvm在疯狂的Full GC,而且有个大对象始终根节点路径可达,无法释放。dump了一下这个实例的内存,发现确实有大对象,占用了一个多G的堆内存。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/花生_TL007/article/detail/185035
推荐阅读
相关标签
  

闽ICP备14008679号