jvm排查问题工具
2023-08-28 22:43:24 0 举报
AI智能生成
jvm常用排查问题工具
作者其他创作
大纲/内容
评判 GC 的两个核心指标
延迟 : 也可以理解为最大停顿时间,即垃圾收集过程中一次 STW 的最长时间,越短越好,一定程度上可以接受频次的增大
吞吐量 :应用系统的生命周期内,由于 GC 线程会占用 当前可用的 CPU 时钟周期,吞吐量即为 有效花费的时间占系统总运行时间的百分比
常用命令
JPS
进程信息
进程信息
jps主要用来输出JVM中运行的进程状态信息
语法格式: jps [options] pid
如果不指定hostid就默认为当前主机或服务器。
-q 不输出类名、Jar名和传入main方法的参数
-m 输出传入main方法的参数
-l 输出main类或Jar的全限名
-v 输出传入JVM的参数
示例
jps
子主题
jps -v
子主题
JINFO
查看jvm配置信息
查看jvm配置信息
jinfo是实时地查看和调整虚拟机各种参数。
语法格式:jinfo [options] pid
jinfo -sysprops pid 或者 jinfo pid 输出当前 jvm 进行的全 部的系统属性
jinfo -flag xx pid 输出指定参数
jinfo -sysprops pid 或者 jinfo pid 输出当前 jvm 进行的全 部的系统属性
jinfo -flag xx pid 输出指定参数
jstat
查看虚拟机运行状态
查看虚拟机运行状态
对Java应用程序的资源和性能进行实时的监控
语法格式如下:
jstat generalOption vmid, [ interva,count ]
jstat generalOption vmid, [ interva,count ]
generalOption: 一般使用-gcutil查看GC情况
vmid: 虚拟机进程号,即当前运行的java进程号
interval: 间隔时间,单位为秒或毫秒
count: 打印次数,如果缺省则打印无数次
示例
查询GC总体使用情况:jstat -gcutil pid1000 5
每秒统计1次,共同机5次
子主题
子主题
垃圾总体回收统计:jstat -gc pid1000 5
新生代垃圾回收统计:jstat -gcnew pid 1000 5
堆内存统计:jstat -gccapacity pid1000 5
新生代堆内存统计:jstat -gcnewcapacity pid1000 5
老年代统计:jstat -gcoldcapacity pid1000 5
其他命令
jstack
线程分析工具
线程分析工具
用于生成虚拟机当前的线程快照
用法
jstack [-l] <pid>
jstack -F [-m] [-l] <pid>
jstack [-m] [-l] <executable> <core>
示例
jstack 7 | grep ‘47365’
查询进程为7的所有线程信息,并过滤出
线程信息中包含47365的线程
查询进程为7的所有线程信息,并过滤出
线程信息中包含47365的线程
子主题
main 线程名称
prio 线程优先级
tid JVM线程的id
nid 系统线程id
waiting on condition 系统线程状态
系统线程状态包括
deadlock 死锁
线程处于死锁状态,将占用系统大量资源。
runnable 线程正在执行状态中
blocked 阻塞状态
waiting on condition 线程正处于等待资源或等待某个条件的发生
系统线程处于此种状态说明它在等待另一个条件的发生来唤醒自己,或者自己调用了sleep()方
法。如果大量线程处于此种状态,说明这些线程又去获取第三方资源了,比如第三方的网络资
源或读取数据库的操作,长时间无法获得响应,导致大量线程进入等待状态。因此,这说明系
统处于一个网络瓶颈或读取数据库操作时间太长
法。如果大量线程处于此种状态,说明这些线程又去获取第三方资源了,比如第三方的网络资
源或读取数据库的操作,长时间无法获得响应,导致大量线程进入等待状态。因此,这说明系
统处于一个网络瓶颈或读取数据库操作时间太长
waiting for monitor entry 或 in Object.wait() 线程在互斥和协作过程中
系统线程处于这种状态说明它在等待进入一个临界区,此时JVM线程的状态通常都是
java.lang.Thread.State: BLOCKED 如果大量线程处于这种状态的话,可能是一个全
局锁阻塞了大量线程。如果短期内多次打印Thread Dump信息,发现
waiting for monitor entry 状态的线程越来越多,没有减少的趋势,可能意味着某些
线程在临界区里呆得时间太长了,以至于越来越多新线程迟迟无法进入
java.lang.Thread.State: BLOCKED 如果大量线程处于这种状态的话,可能是一个全
局锁阻塞了大量线程。如果短期内多次打印Thread Dump信息,发现
waiting for monitor entry 状态的线程越来越多,没有减少的趋势,可能意味着某些
线程在临界区里呆得时间太长了,以至于越来越多新线程迟迟无法进入
[0x000...25000] 起始栈地址 线程堆栈调用的其实内存地址
TIME_WAITING VM线程状态
线程状态
NEW 线程刚被创建,但尚未启动
RUNNABLE 可运行线程的线程状态
running 可运行状态(runnable)的线程获得了cpu 时间片(timeslice) 执行程序代码
blocked 受阻塞并且正在等待监视器的某一线程的线程状态
WAITING 线程正在无期限地等待另一个线程来执行某一个特定的操作
TIMED_WAITING 指定了等待时间的某一等待线程的线程状态
TERMINATED 线程处于终止状态
jmap
内存快照工具
内存快照工具
一方面是获取dump文件(堆转储快照文件,二进制文件),它还可以获取目标Java进程的内存相关信息,包括Java堆各区域的使用情况、堆中对象的统计信息、类加载信息等
用法
jmap [option] pid
-dump 生成dump文件
-heap 输出整个堆空间的详细信息,包括GC的使用、堆配置信息,以及内存的使用信息等
-histo 输出堆空间中对象的统计信息,包括类、实例数量和合计容量
常见问题排
cpu异常飙高问题
找到最耗CPU进程
top
最耗CPU的进程PID为291684
子主题
找到最耗CPU线程
top -Hp pid
(docker环境这个命令可能有问题)
(docker环境这个命令可能有问题)
指定进程内,最耗CPU的线程PID为291685
将线程PID转化为16进制:printf "%x\n" 291685
之所以要转化为16进制,是因为堆栈里,线程id是用16进制表示的
查看堆栈 定位线程在做什么,定位对应代码
jstack 291684 | grep '47365'
子主题
内存OOM
常见的原因:
有可能是内存分配确实过小,而正常业务使用了大量内存
某一个对象被频繁申请,却没有释放,内存不断泄漏,导致内存耗尽
某一个资源被频繁申请,系统资源耗尽,例如:不断创建线程,不断发起网络连接
分析步骤
1.确认是不是内存本身就分配过小
jmap -heap 11155
jmap -heap 11155
可以查看新生代,老生代堆内存的分配大小以及使用情况,看是否本身分配过小。
2.找到最耗内存的对象
jmap -histo:live 11155| more
会以表格的形式显示存活对象的信息,并按照所占内存大小排序
会以表格的形式显示存活对象的信息,并按照所占内存大小排序
jmap -dump:format=b,file=jmap.dump pid
生产对应的快照文件,然后查看
生产对应的快照文件,然后查看
也可以通过配置自动实现导出文件
-XX:+HeapDumpOnOutOfMemoryError
OOM的时候自动dump内存快照出来
OOM的时候自动dump内存快照出来
-XX:HeapDumpPath=/usr/local/app/oom
把内存快照放到哪儿去
把内存快照放到哪儿去
3.确认是否是资源耗尽
pstree
netstat
arthas
安装
wget https://arthas.aliyun.com/arthas-boot.jar
下载
下载
java -jar arthas-boot.jar
启动arthas
启动arthas
top N线程
thread -n 3
最忙的前N个线程并打印堆栈
最忙的前N个线程并打印堆栈
thread -n 3 -i 5000
查看5秒内的CPU使用率top n线程栈
查看5秒内的CPU使用率top n线程栈
thread -b
找出当前阻塞其他线程的线程
找出当前阻塞其他线程的线程
thread
列出所有线程
列出所有线程
dashboard
查看当前系统的实时数据面板
查看当前系统的实时数据面板
输入 Q 或者 Ctrl+C 可以退出dashboard命令
quit
JVM
JVM的各种详细信息
JVM的各种详细信息
常用调优配置
堆内存大小设置
-Xms -Xmx -XX:NewSize -XX:NewRatio -XX:SurvivorRatio -XX:MaxPermSize
垃圾收集器设置
-XX:+CMSIncrementalMode
垃圾回收统计信息
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-Xloggc:filename
0 条评论
下一页