在长期排查线上问题的过程中,总结了一些工具的用法和排查问题的思路,这里跟大家分享一下,在遇到类似的问题时,希望能给予一些帮助。
首先讲讲工具,JVM自带的一些工具是必须熟练掌握的,例如jstack, jmap, jstat等,它们可以帮我们去深入了解JVM正在做的事情,主要的适用领域有这些:
1、jstack
jstack可以告诉你当前所有JVM线程正在做什么,包括用户线程和虚拟机线程,你可以用它来查看线程栈,并且结合Lock信息来检测是否发生了死锁和死锁的线程。
没事儿jstack一下,知道你的小伙伴正在做什么。
另外在用top -H看到占用CPU非常高的pid时,可以转换成16进制后在jstack dump出来的文件中搜索,看看到底是什么线程占用了CPU。
2、jstat
stat,顾名思义就是提供一些统计信息,它可以告诉你当前的GC情况,包括GC次数、时间,具体的GC还可以结合gc.log文件去分析。
一般来说,我们用jstat去查看GC情况,判断是否存在YGC或FGC频繁的情况,再去看gc.log和jamp dump内存,MAT分析来定位问题(后面会有一个case针对这种场景)。
常用的用法是jstat -gcutil pid time(间隔)
3、jmap
排查GC问题必然会用到的工具,jmap可以告诉你当前JVM内存堆中的对象分布及其关系,当你dump堆之后可以用MAT分析,看看有哪些大对象,或者哪些类的实例特别多。
常用用法:强制FGC:-histo:live
dump堆:-dump:[live],format=b,file=dump.bin
查看各代内存占用情况:-heap
然后我们来介绍一些开源的工具,来增强JVM工具本身的作用。
1、MAT(Eclipse Memory Analyzer)
GC分析必备,用于分析jmap或OOM时dump出来的内存快照,可以看到对象和引用关系。
2、top
这个是Linux自带的命令,查看系统资源消耗情况,可以看看CPU、内存、SWAP、I/O的消耗情况,需要特别注意的有几个值:
ni,这个值如果特别高说明线程上下文切换开销较大,看看是不是开了太多的线程导致的
res,这个代表了进程实际占用的内存
swap,内存不足就会占用swap空间,这个时候一般应用的性能会急剧下降,需要特别关注
3、HouseMD
一个类似于BTrace的工具,用于对JVM运行时的状态进行追踪和诊断,作者是中间件团队的聚石。
通常我们排查问题很多时候都在代码中加个日志,看看方法的参数、返回值是不是我们期望的,然后编译打包部署重启应用,十几分钟就过去了。HouseMD可以直接让你可以追踪到方法的返回值和参数,以及调用次数、调用平均rt、调用栈。甚至是类的成员变量的值、Class加载的路径、对应的ClassLoader,都可以用一行命令给你展现出来,堪称神器。
更多的用法可以参考详细的WiKi:https://github.com/CSUG/HouseMD
再偷偷告诉你,因为HouseMD是基于字节码分析来做的,所以理论上运行在JVM的语言都可以用它,包括Groovy,Clojure都可以。
4、TBJMap
通过jmap和MAT我们可以知道整个JVM堆的对象分布情况,但是有时候我们需要知道young/old/perm区分别有哪些对象的时候,就要用到TBJMap这个神器了。作者是中间件团队的叔同。
他可以告诉你各个分代区各个Class的实例数、占用的空间,以及DirectMemory占用的空间等。
用法很简单,一行命令即可。WiKi:https://github.com/alibaba/TBJMap