visualvm工具远程对linux服务器上的JVM虚拟机进行监控与调优

朱季谦 • 2023-01-02 • 云技术社区 • 271 阅读

文/朱季谦

最近做了一些JVM监控与调优的事情，算是第一次实践，还比较陌生，故而先把这一次经验简单记下笔记，这样，对后面学习调优方面时，不至于又想不起来了。

本文档主要总结在window本地环境远程对linux服务断的JVM虚拟机进行监控与调优的方法。

visualvm工具是JDK自带的，在java安装目录下可以找到：C:\\Program Files\\Java\\jdk1.8.0_77\\bin

打开visualvm工具，右击远程，添加远程主机——

在弹出框上的主机名处，填写需要连接的服务器IP——

添加成功后，右边框就出现了以下图标——

这时，右击“42.194.xx.xx”，会看到，有两种远程连接方式，一个是JMX，一个是jstatd。

这里主要分享是以jstatd模式。在以jstatd模式连接前，需要在监控的远程服务端启动jstatd，启动步骤如下——

找到服务端jdk的bin目录，新建jstatd.all.policy文件
将以下内容复制到jstatd.all.policy文件里——
grant codebase "file:${java.home}/../lib/tools.jar" { permission java.security.AllPermission; };
保存，设置权限——
[root@VM-16-4-centos bin]# chmod 777 jstatd.all.policy
设置成功——

[root@VM-16-4-centos bin]# whereis java
java: /usr/bin/java 
[root@VM-16-4-centos bin]# cd /usr/bin/
[root@VM-16-4-centos bin]# vim jstatd.all.policy

在监控的远程服务端启动jstatd
执行 jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=42.194.xxx.xx &
注：42.194.xxx.xx 是我个人腾讯云机器IP。
这时，观察visualvm工具右边栏菜单，可以看到远程连接的服务端已经自动连接上jstatd，这就意味着，可以在本地通过远程jstatd来监控开发服务器上的jvm信息了，从而进行jvm调优监控等操作。

点击其中一个进程biz-0.0.1-SNZPSHOT.jar，就可以进入到对应的监控台——

visualvm控制台有概述、监视、抽样器等菜单，同时，可以装入插件扩展功能——

概述

可以看到jvm参数、系统属性、jdk版本与安装路径等信息；
设置的jvm参数，这里新生代分配了最小堆空间是256m，最大堆空间是256m，新生代128m，元空间是128m，堆=新生代+老年代，不包括永久代（方法区），这就意味着，这配置当中的老年代=256m。
-Xms256M -Xmx256M -Xmn128M -XX:PermSize=128M -XX:MaxPermSize=256M
这些都是指定JVM参数运行对应的jar进程，除此之外，还有其他参数可做设置。

监视

监控模块可以实时看到进程所在的堆、元空间、类及线程的报表数据监控，其中，堆和元空间的报表对调优可以起到很有用的帮助。

[root@VM-16-4-centos bin]#  jstatd -J-Djava.security.policy=jstatd.all.policy -J-Djava.rmi.server.hostname=42.194.xxx.xx &
[1] 52056

除了visualvm自带的功能外，我们需要装入一个实时监控GC的插件visualgc，这个插件很方便对JVM做监控与调优。

考虑到visualgc插件通过官网下载很慢，我已经保存在网盘当中，可直接通过网盘进行下载——

链接：https://pan.baidu.com/s/17TSf0ZdFtMdfog6xzbj3ZQ 提取码：el6c

插件装载方式，右击工具栏，选择插件——

弹出框后，点“已下载”按钮，再点击“添加插件”将需要安装的visualgc插件添加进来——

安装成功后，重启一下visualvm，就可以看到菜单栏上多出一个Visual GC插件——

Visual gc 工具分成布局分成三部分，可在右上角对应方框里勾选【Space】【Graphs】【Histogram】，它们各自的作用——

可视化GC窗口（space）
图形统计窗口（Graphs）
幸存者年龄直方图窗口（Histogram）

下面分别介绍各自窗口与其显示的数字表示——

可视化GC窗口（space）
VisualGC窗口是最左的窗口，分成三条垂直柱体，在JDK1.8版本中，分别代表metaSpace元空间、Old老年代、新生代，其中新生代又划分成 Eden 区， S0 区， S1区三部分。柱体里颜色部分代表占用的空间，空白部分表示剩余空间。监控项目的堆进程时，这些代表颜色的地方都是动态变化的。

图形统计窗口（Graphs）
图形窗口显示各种统计值随时间的变化。
一、Compile Time
显示将Java字节代码编译为本机代码所花费的时间量。窄脉冲表示持续时间相对较短，宽脉冲表示持续时间较长。
- 编译任务的数量5508；
- 累计编译时间27.721s。

二、Class Loader Time
此面板显示在类加载和卸载活动中花费的时间量。窄脉冲表示持续时间相对较短，宽脉冲表示持续时间较长。

加载的类数量：11337；
卸载的类的数量：0
累计的类加载时间：15.589s

三、GC Time
此面板显示垃圾收集活动所花费的时间量。窄脉冲表示持续时间相对较短，宽脉冲表示持续时间较长。

执行GC垃圾回收总次数：9次（9 collections代表自监视以来执行9次GC，其中，包括新生代的Minor GC和老年代的Full Gc）
累计的GC时间:888.929ms；
若JVM维护hotspot.gc.cause和hotspot.gc.last_cause计数器，则gc事件的原因将出现在last Cause中；

四、Eden Space
此面板显示Eden空间随时间的利用情况。它是年轻代的三个空间之一，另外两个分别是S0、S1。空间的当前容量可以根据收集器策略动态更改，即通过修改--Xmn参数，会改变其大小。
标题栏第一个参数代表最大容量，第二个参数代表当前容量，后跟当前占用空间。此外，还包含了年轻代GC事件数量和GC累计时间。

Eden Space最大可分配空间：102.500M；
Eden Space当前已分配空间：102.500M；
Eden Space当前占用空间：54.523M(当积累的占用空间超过102.500M，就会在Eden Space发生一次Minor GC)
Minor GC次数：6次
Minor GC花费时间：286.621ms

五、Survivor 0 and Survivor 1
HotSpot JVM把年轻代分为了三部分：1个Eden区和2个Survivor区（分别叫from和to），默认大小比例为Eden:Survivor0:Survivor1=8:1:1的。　新创建的非大对象，会存放在Eden区和一个作为from的Survivor区，当发生一次Minor GC时，就会将Eden区和作为from的Survivor区内仍存活的对象，复制到另一个作为to的Survivor区，然后清理掉原来Eden区和作为from的Survivor区内对象。因此，S0 和 S1 之间至少有一个肯定是空闲的。

Survivor 0区最大分配容量：12.750M；
Survivor 0区当前已分配容量：12.750M；
Survivor 0区当前占用容量：0M；

五、Old Gen
面板显示老年代随着时间推移的利用情况。

Old Gen 最大分配空间128M；
Old Gen 已分配空间128M；
Old Gen 当前占用空间38.06M；
Old Gen 发生的GC次数：3次；
Old Gen 发生的GC花费时间：602.309ms；

六、Perm Gen
标题栏在括号中显示空间的名称及其最大容量和当前容量，后跟空间的当前占用大小。

visual VM工具的相关功能使用主要就介绍那么多，下面就介绍一下入门调优的案例，小白都能看懂的。
假如某天你观察到使用visual VM工具的Visual GC插件观察到以下的图表——新生代Eden区已经发生了8168次Minor GC，耗时39.754s,另外老年代也发生了24次GC，耗时5.124s。可见，该JVM参数设置得极不合理，导致已经过于频繁发生Minor GC。

那么，我们该如何调优进行设置呢？

JVM调优无外乎就是对相关参数进行设置，这里，我们先做一些最简单的参数，好让小白也能理解，那么，就暂时先对-Xms、-Xmx、-Xmn参数设置。

截图中，可以看到新生代中的Eden区频繁发生Minor GC，原因之一是分配的空间过小，目前是204.875M，导致当前占用空间经常超过204.875M，进而发生GC。若要分析是哪些代码频繁创建对象，还得进一步通过dump等方式进行分析，这里暂时不展开。

解决该Eden区其中一个思路是，提升分配给Eden区的大小。

那么，多大才比较合适呢？

这时，Visual VM的监视栏中的堆监控就派上用场了。可以观察到蓝色模块高度比较均衡地对应在纵坐标240MB的样子，也就是说，新创建的对象其占有的大小达到近300MB，而Eden Space+其中一个Survivor才230MB，可见，每次新创建的对象很容易就超过新生代，这就意味着，频繁发生Minor GC是必然的，从图的横坐标可以看出，每30ms内，就发生了2到3次的Minor GC。

为了避免Eden区频繁发生Minor GC，根据堆监控图表，可以考虑在设置JVM参数时，适当提升分配给Eden的空间，至少需要在240MB以上，可以考虑先设置到300MB的样子，看下效果，当然，这是在项目比较平稳运行的情况下来看的，实际生产当中，还需要考虑到高峰时期。

就暂且先设置Eden区为320MB，考虑到Eden:Survivor0:Survivor1=8:1:1比例，也就是8:2，若要分配Eden=320M，那么，可以根据8/2=320/x算出来，x=80，这里的x就是两个Survivor总大小，即每个Survivor分配40MB，那么，年轻代总共需要分配的大小为（320M+80M）=400M，即-Xmn400m

再来看下老年代，目前老年代发生了24次GC，最大分配空间是256MB，当前最小分配空间是71.48M，可见，还可以适当进行优化。

一般而言，最大分配空间与最小分配空间最好保持一致,这样避免每次空间不够时都需自动提升当前分配大小。

可以暂且考虑最大分配空间与当前分配空间都保持在256M，而根据堆=新生代+老年代，不包括永久代（方法区）。在新生代已经分配300MB情况下，若要让老年代最大与最小分配空间都为256MB，那么，就需要对JVM堆分配400M+256M=656M的空间大小，即设置-Xms656M、-Xmx656M；

元空间暂且可以不考虑进行分配。

根据以上得出的参数，进行设置，然后以设置好的参数进行项目重启，根据新一轮图表展示，继续进行参数优化，循环调试，直到新生代和老年代的GC频率都保持一个比较平衡的水准。

以上，就是主要介绍了JVM监控与调优工具，同时，简单说明了一下如何进行参数调优，实际上，还需调试更多JVM相关参数，才能达到优化效果，至于其他的JVM参数调试，本文暂且不展开介绍了。

最后，需要注意一点，本地环境使用jstatd模式远程连接线上服务端的JVM时，是不能在本地获取到堆栈信息的，可以手动生成dump文件来分析出现异常的堆栈信息。

一、设置参数在异常发生时自动生成dump文件。