2022-02-23—项⽬如何排查JVM问题
你们项⽬如何排查JVM问题?
一、对于还在正常运⾏的系统:
- 可以使⽤jmap来查看JVM中各个区域的使⽤情况。
jmap pid查看进程的内存映像信息,类似 Solaris pmap 命令。
jmap -heap pid 显示Java堆详细信息。 |
jmap -histo:live pid 显示堆中对象的统计信息。 |
可以通过jstack来查看线程的运⾏情况,⽐如哪些线程阻塞、是否出现了死锁.
jstack pid
可以通过jstat命令来查看垃圾回收的情况,特别是fullgc,如果发现fullgc⽐较频繁,那么就得进⾏调优了。
jstat -gc pid 垃圾回收统计
Jstat -gc 74589 250 10
命令的意思是:每隔250毫秒查询一次进程为74589的垃圾收集情况,一共查询10次。- S0C:第一个幸存区的大小
- S1C:第二个幸存区的大小
- S0U:第一个幸存区的使用大小
- S1U:第二个幸存区的使用大小
- EC:伊甸园区的大小
- EU:伊甸园区的使用大小
- OC:老年代大小
- OU:老年代使用大小
- MC:方法区大小
- MU:方法区使用大小
- CCSC:压缩类空间大小
- CCSU:压缩类空间使用大小
- YGC:年轻代垃圾回收次数
- YGCT:年轻代垃圾回收消耗时间
- FGC:老年代垃圾回收次数
- FGCT:老年代垃圾回收消耗时间
- GCT:垃圾回收消耗总时间jstat -gcutil pid 总结垃圾回收统计
通过各个命令的结果,或者jvisualvm等⼯具来进⾏分析。
⾸先,初步猜测频繁发送fullgc的原因,如果频繁发⽣fullgc但是⼜⼀直没有出现内存溢出,那么表示 fullgc实际上是回收了很多对象了,所以这些对象最好能在younggc过程中就直接回收掉,避免这些对 象进⼊到⽼年代,对于这种情况,就要考虑这些存活时间不⻓的对象是不是⽐较⼤,导致年轻代放不下,直接进⼊到了⽼年代,尝试加⼤年轻代的⼤⼩,如果改完之后,fullgc减少,则证明修改有效。
同时,还可以找到占⽤CPU最多的线程,定位到具体的⽅法,优化这个⽅法的执⾏,看是否能避免某些 对象的创建,从⽽节省内存。
二、对于已经发⽣了OOM的系统:
⼀般⽣产系统中都会设置当系统发⽣了OOM时,⽣成当时的dump⽂件。
(- XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/base)我们可以利⽤jvisualvm等⼯具来分析dump⽂件。
使用
jmap
dump出文件进行查看
查看堆内存信息 |
把dump文件在jvisualvm里打开。或者上传到网站 https://heaphero.io/index.jsp 进行分析
4. 使用jstack查询线程相关信息
jstack 命令dump出信息,到分析工具分析 |
或者使用https://fastthread.io/
在线分析工具。
使用方法是将程序jstack出来然后上传文件到上面网址就行,命令是jstack -l 56523 > 56523.jstack
- 根据dump⽂件找到异常的实例对象,和异常的线程(占⽤CPU⾼),定位到具体的代码。
- 然后再进⾏详细的分析和调试 总之,调优不是⼀蹴⽽就的,需要分析、推理、实践、总结、再分析,最终定位到具体的问题。
三、演示一套行云流水的操作
1、使用uptime查看当前load,发现load飙高
➜ ~ uptime |
2、使用top命令,查看占用CPU较高的进程ID
➜ ~ top |
发现PID为1893的进程占用CPU 181%,而且是一个Java进程,基本断定是软件问题
3、使用 top命令,查看具体是哪个线程占用率较高
➜ ~ top -Hp 1893 |
4、使用printf命令查看这个线程的16进制
➜ ~ printf %x 4519 |
5、使用jstack命令查看当前线程正在执行的方法
➜ ~ jstack 1893 |grep -A 200 11a7 |
6、使用jmap内存使用的详细情况输出到文件,之后一般使用其他工具进行分 析
➜ ~ jmap -dump:format=b,file=heapDump 1893 |
2022-02-23—项⽬如何排查JVM问题
https://peialan.github.io/2022/02/23/2022-02-23—项⽬如何排查JVM问题/