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

最新推荐文章于 2022-05-25 19:45:21 发布

航天拍卖

最新推荐文章于 2022-05-25 19:45:21 发布

阅读量685

点赞数

文章标签：如何查java当前负载

本文链接：https://blog.csdn.net/weixin_36335651/article/details/114790501

版权

本文介绍了如何在Linux系统中排查Java进程的CPU高负载问题，通过`top -H`、`htop`、`ps`等命令观察进程和线程状态，以及使用`jstack`进行线程堆栈分析，最终发现由于大对象导致的`OutofMemoryError: GC overhead limit exceeded`问题。

摘要由CSDN通过智能技术生成

前言

通过本文，你将学会：

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

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

查看所有进程信息 top -H

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

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

轻量级进程(LWP)

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

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

实验观察

某个时刻下的截图

个别时间下出现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个线程，如下图所示：

上图是截图左半部分

上图是截图右半部分

pstree -p 22564

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

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的堆内存。