jvm 命令使用调优 通过jstat、jmap对java程序进行性能调优

不问归期 提交于 2020-02-16 11:39:58

转载:http://blog.csdn.net/jerry024/article/details/8507589

转载: https://blog.csdn.net/zhaozheng7758/article/details/8623530

 

通过jstat、jmap对java程序进行性能调优

第一次写技术博客,本文记录了我对服务器cpu占用率100%问题的排查过程和最终结果,算是一篇学习日志。

 

本人属于学习中的菜鸟码农,如有什么理解上的偏差的,还请各路大神指正。

 

关键词:

jstat , jmap, heap, GC, smartupload, 内存泄漏

 

1. 背景

硬件供应商多次反映,在tomcat启动一段时间后,经常出现cpu占用率100%,且重启前一直保持在100%的情况。在重启后cpu占用率回落,但是一段时间后再次出现问题。

下图为cpu占用率100%时使用top命令的截图,可以看到java进程的cpu占用率几经几乎达到了400%(服务器为4核cpu)

 

<1><1>

2.问题定位

2.1问题猜测

对于cpu占用率100%的情况,产生以下两种猜测:

a. 程序长时间占用系统IO,导致CPU占用率100%

b.程序存在严重内存泄露,导致jvm频繁执行full GC,从而使cpu占用率提高,造成服务器假死

 

2.2jvm的内存管理和垃圾回收机制

java对内存的管理主要分为两种:栈(stack)和堆(heap) 方法区,程序计数器等不做讨论

 

stack: 在每个线程启动时由jvm自动分配固定大小的地址,stack内主要保存操作符,值对象(int,float等基础数据类型),和引用对象的指针由于stack固定大小,且主要操作为push和pop,并不涉及到垃圾回收等问题,因此不做展开。

heap:堆在线程执行过程中自动分配大小,大小可以随时改变,主要用于保存对象(Object),对象在结束生命周期结束之后便会由JVM的垃圾回收机制自动进行回收堆可分为3大部分年轻代(Young Generation)、年老代(Old Generation)和持久代(Permanent Generation)。

年轻代:年轻代又可分为3个小区:Eden,两个等大的Survior区(from 和 to)。其中Eden主要存放新建的对象,当Eden区无法再存放更多的对象时,jvm会发起年轻代GC(Minor GC),释放Eden中的对象,Minor GC的特点是发生频率高,执行速度也极快,对系统效率的影响并不是很大。当Eden区中的对象经过一次Minor GC仍然没有被释放时,这部分对象将被移入Survior区(对象可能进入from区,也可能进入to区,有具体算法,此处不做展开)。当Survior区中的对象经历过数次的Minor GC之后仍然存活,将被移入年老代。

年老代:年老代中用来存放从年轻代过来的长时间使用的对象,大部分的JVM内存溢出错误均发生在这个区域。当年老代被过度占用,无法存放下更多的数据时,jvm会发起一次年老代GC(Major GC\Full GC),该类型GC会释放年老代中的资源,虽然该GC触发频率很低,但是对硬件资源的消耗较高,且Full GC过程中会暂停该线程的执行。如果系统中存在内存泄露,频繁的触发Full GC,将会严重的占用服务器资源,造成应用的假死,这也是我之前猜测b的依据。

 

持久代:持久代中用于存放jvm的反射类等,如class等,此区域对GC的影响不大,也不大会发生内存溢出的情况。

 

下图是引用网上的一张图片,更形象的描述了heap区的构成

<2><2>

 

2.3jstat、jmap实战

ok,在弄清楚jvm的GC机制之后,就有了努力的方向了,为了弄清楚GC具体的工作情况,就要使用到jstat命令了。

jstat(Java Virtual Machine Statistics Monitoring Tool)是jdk自带的监控工具,位置在%JAVA_HOME%/bin 下,命令使用方法为

 jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

下图是我对系统中tomcat进程的监控情况

<3><3>

<4><4>

命令中 -gcutil表示统计GC情况,5125为tomcat的pid,10000表示没10s统计一次,5表示一共统计5次

结果中s0为from区,s1为to区,E为Eden区,O为Old区,P为Permanent区,YGC为yong GC次数,YGCT为yong GC执行的总时间,FGC为Full GC次数,FGCT为Full GC总时间,GCT为GC总时间。

上面图<3>为cpu占用率高时的截图,图<4>为正常情况下截图。

很明显的看到GC次数相差不大的情况下,GC耗时存在很大的差距,推测此时系统中可能存在内存泄漏的情况。

 

为了确定jvm中具体有哪些生存的对象,就需要用到jdk自带的另一个监控工具,jmap了

jmap(Memory Map)用于监控系统内存中存活的对象。

使用命令: jmap -histo:live 5125>> /opt/jmap.txt  

其中5125为pid ,由于数据较多,将数据保存在txt文件中进行分析,下图列出了对内存占用排名前几的对象

<5><5>

一眼看去,String对象稳居第一,好吧,项目中对String的处理确实有不少问题,但是,排名第三的这是什么东西?!

在代码中一查,这个对象只在一个上传文件中的Servlet中被用到了一次,很明显的内存泄漏!

 

3.问题解决

很明显,jspsmart这个插件正是内存泄漏的元凶,网上查找资料之后确定,jspsmart由于自身bug,在长时间运行后会产生两个严重问题:
a. 客户端在未完成上传时便主动终止了上传操作,此时客户端不再上传文件,但是服务端仍然会占用InputStream,并且不会主动释放,造成cpu占用率100%,猜测a证实
b. 客户上传的文件损坏,在创建File对象时无法找到文件终止标识,因此一直在创建新的File对象,造成内存泄漏。
 
由此,服务器内存溢出和cpu占用率100%两个问题都找到了关键所在,接下来的工作就像对简单了,使用apache的开源项目commons-upload替换原来的jspsmart来完成文件上传的工作,替换过后,系统资源占用正常,附上bug修复后的jmap截图
<6><6>
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!