利用jvisualvm解决线上应用高内存占用问题(一)-如何连接远程jvm

    最近项目新上线一次重构版本，彻头彻尾的重构也就意味着每一句代码都是新写的。历时3个月的开发测试上线的头一周一直在解决各种bug。到了第二周业务逻辑没再出现bug，系统算是稳定下来，但发现系统在运行几天后jvm常驻内存持续升高不减，用到4g以外，内存占比长期保持56%(应用访问无明显变化)。top命令查看结果如下：

通过jstat查看进程的回收过程表现也很正常。

    为了搞清楚为什么常驻内存会在4g开外打算利用jvisualvm来看看在远程的jvm中内存使用到底是什么情况。废话不多说了直接看如何连接远程jvm吧。

第一步：在远程jvm启动参数中加入远程调用所需的jmx信息：
1）在要被监控的远程应用的tomcat/bin中添加setenv.sh ， 文件内容如下：JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=主机ip(如113.89.78.178)
-Dcom.sun.management.jmxremote.port=18999
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.password.file=/xxxx/tomcat7/conf/jmxremote.password
-Dcom.sun.management.jmxremote.access.file=/xxx/tomcat7/conf/jmxremote.access
-Dcom.sun.management.jmxremote.authenticate=true"
简单的说明下参数内容吧：
java.rmi.server.hostname 是要被监控的主机外网IP
com.sun.management.jmxremote.port 是被远程监控的端口，注意不要和别的项目有冲突
com.sun.management.jmxremote.ssl 是远程监控连接是否需要用ssl证书，选择false即可
com.sun.management.jmxremote.password.file 是监控是允许访问的账号密码文件，在此文件中的账号密码可以自定义，稍后再说
com.sun.management.jmxremote.authenticate 是指远程连接时是否需要用户账号，线上建议true

2)setenv.sh文件建立好后需要给文件赋权限，执行 chmod +x setenv.sh 。

3）在/xxx/tomcat7/conf路径下建立上面提到的jmxremote.access和jmxremote.password文件。
jmxremote.password内容如下：
test test123456  
monitorRole  QED    
controlRole  R&D
说明一下：test是自定义的连接账号,空格后为该账号的密码，需要和远程jvm发布时的账号密码一致。在这里自定义了后需要在jmxremote.access中定义，具体一会讲到，monitorRole和controlRole为系统默认账号。
jmxremote.access内容如下：
test  readwrite
monitorRole  readonly
controlRole  readwrite \ create javax.management.monitor.*,javax.management.timer.* \  unregister
4）为两个文件赋权限：执行命令 chmod 600 jmxremote.password  , chmod 600 jmxremote.access
5）重新启动tomcat，检查进程中是否已经加载了启动项，如果服务正常则第一步已经完成，第二部就简单了。

第二步：本地启动jvisualvm连接远程JVM
1)在自己装的jdk文件夹中的bin目录里找到jvisualvm，启动它即可。界面如下：

2）在远程上右键，添加远程主机

3）主机名为远程要访问的外网IP。添加确定后左侧出现添加的远程主机

4）在要连接的远程主机IP上右键，选择添加jmx连接。

5）连接中出现主机ip: , 在冒号后面添加setenv.sh里设定的监控端口。 用户名，口令为jmxremote.password文件中设置的自定义账号密码，勾选上下面两条后保存即可。
正常情况下，左侧远程主机下会出现jvm的进程监控会话，点击即可查看cpu,内存等信息。

至此，远程jvm监控已经在本地添加完毕，中途过程中也遇到不少问题，比如提示jmi无法连接到等问题，可以看看防火墙是否阻挡了你的连接，在iptables中添加你的白名单即可。下一篇在此基础上分析远程jvm的具体运转情况，稍后待续。