性能文章>Java应用一键诊断利器-MProfiler>

Java应用一键诊断利器-MProfiler原创

https://a.perfma.net/img/2382850
1年前
38601210

MProfiler是Java应用一键诊断利器,如果有过诊断经验或对Java诊断相关知识熟悉的话,可能会知道业界一些有名的诊断工具,如Arthas、Async-Profiler、MAT、JProfiler等,这些工具做的都不错,可以从各个角度观察Java应用运行的状态,那么还有必要再做一个Java一键诊断工具吗?如果要单纯卷诊断工具的话,我觉得没有必要,也卷不过他们,除非能做出一些亮点,而MProfiler最大的亮点就是一键诊断。

之前帮助许多开发者解决过各种程序问题,可以简单列举一下这些开发工程师在排查应用过程中遇到的种种问题,如下:

1、生产上的问题,时间少,排查限制多 许多开发者在遇到性能问题时,才会在网上搜索,找一些看似和自己遇到的问题类似的信息,照着这些信息现学现卖不过问题总是千奇百怪,很难在短时间内准确定位出来这时候一个有排查经验的工程师会比新手排查问题要快不少另外生产环境的限制很多,如堆文件太大dump不出来,堆文件太大无法下载到本地,无法上传分析等,还可能遇到开发环境不出问题,但是生产环境出问题的情况,如ClassNotFoundException;

2、不会利用各种工具获取应用数据  之前有开发者问我说,通过堆dump文件分析出某个类型的实例特别多,但是在程序中无法定位到创建实例的地方,还比如globalref的的数量很多 ,但是并不知道其中引用的具体数据的类型是什么;

3、出现了明显异常的数据,仍然没有发现  例如有开发者给我看了栈dump数据,其中有上万个处于Waiting状态的线程,那这就明显可以做为问题的切入点进行排查。

针对开发者遇到的这些问题,我对MProfiler提出了3点要求,下面一一介绍,力求傻瓜式的解决Java应用的各种问题。

1.一键诊断

现在针对Java应用的诊断工具做的好的有很多,但工具虽好还要看谁用,这些工具使用有一定的门槛。对于许多专注业务开发的工程师来说,如果遇到程序问题时,很难马上将这些工具利用起来。MProfiler为了降低工具的使用门槛,立足于一键诊断,这个功能类似于360的一键诊断。

要做到一键诊断,需要经过大量的实践积累,将千奇百怪的问题进行归纳整理,放到相关的类别中,我们可以将Java应用常见的问题归纳为如下几类:

归纳类别的目的是为了找到这些问题的共性,方便使用一些类似的算法排查问题由于程序的问题千奇百怪,五花八门,所以如何根据各种数据精准找到问题切入点并不容易为了能更精准的定位问题,还要获取足够多的数据,包括瞬时数据和实时监控的数据,同时获取的数据要尽可能的全面,所以采集数据是MProfiler最为基础的功能

采集数据的来源主要包括如下几类:

  • gclog

  • heapdump

  • 线程栈dump

  • 字节码增强

  • JVMTI Agent获取实时数据

  • JavaAgent获取实时数据

  • JMX获取实时数据

  • JavaBean

  • Linux系统

简单来说,MProfiler架构只有2层,第一层是获取目标应用程序各种数据的API接口,第2层是基于API实现大量的风险项。

这些获取数据的API要兼顾轻量级、稳定性和兼容性。其中的轻量级指的是,在尽可能不打扰用户应用程序的情况下获取数据。而兼容性是要在不同的JDK版本,不同的虚拟机类型上能够返回友好的信息,操作系统兼容性目前没有考虑,只专注于支持Linux下64位版本。

丰富的风险诊断库

MProfiler通过调用API接口可以获取各种数据,根据这些数据加上诊断逻辑就可以诊断出应用特定的故障和性能问题了。

MProfiler初步筛选出的一部分典型的诊断项如下:

目前关于风险库筛选的逻辑是,尽量将最为常见的问题纳入进来,当然后续也有开源的打算,借助开源的力量添加更多的风险库,包括各个框架和中间件的issue等。MProfiler最终的目标就是,当应用遇到性能问题或出现故障(或即将出现故障)时,能够使用尽可能丰富的风险库准确圈定问题,然后给出详细提示,如提示触发了某个框架的issue。

从发现、报告到解决全流程指导

MProfiler在精准定位问题后,一定会给出异常指标信息和解决方案,以求从发现问题、报告问题到解决方案全流程指导,让Java性能问题的排查变的更简单。

需要说明的是,MProfiler无论做的有多完善,总有覆盖不到的问题,这时如果能提供一些异常指标和切入点也是非常有帮助的MProfiler能够做的就是列出与异常指标相关的所有数据,然后自己切换到专家模式,这种模式和Arthas一样,需要自己输入命令来排查问题,不过这不是MProfiler愿意看到的。

现在我们回过头来看一下本文开头提到的那3个问题,MProfiler是如何解决的?

1、生产上的问题,时间少,排查限制多 在服务器上直接使用命令行运行MProfiler的一键诊断即可,不在万不得已情况下不需要自己切换到专家模式进行排查,同时也不存在dump文件的下载,上传等操作,所有的操作都在服务器上完成,所以也不用担心敏感信息泄漏的问题;

2、不会利用各种工具获取应用数据  一键诊断不需要自己获取数据,所有必要的数据MProfiler会自己获取,如果某些数据有异常,如实例过多,则会给出引用路径和创建实例的调用栈信息,如果globalref过多,会在一键诊断完成后给出引用的相关数据的类型等信息;

3、出现了明显异常的数据,仍然没有发现  MProfiler会结合算法和经验来排查异常数据,最终也会在一键诊断完成后给出可能的异常数据。

简单介绍一下MProfiler一键诊断工具

通过mprofiler.sh脚本启动MProfiler后,会列出所有活跃的Java进程,选择要检测的目标进程,这里选择序号为1的Main程序,attach成功后会显示MRPOFILER字样的logo,如下:

同时还会列出目前已经支持的所有风险项,以及操作这些风险项的命令:

我们可以使用exec all 命令一键运行所有已经实现的风险项,如果有问题,则会标红提示,并给出一些解决方案

 

点赞收藏
鸠摩

著有《深入解析Java编译器:源码剖析与实例详解》、《深入剖析Java虚拟机:源码剖析与实例详解》等书籍。公众号“深入剖析Java虚拟机HotSpot”作者

请先登录,查看12条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

JDBC PreparedStatement 字段值为null导致TBase带宽飙升的案例分析

JDBC PreparedStatement 字段值为null导致TBase带宽飙升的案例分析

随机一门技术分享之Netty

随机一门技术分享之Netty

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

MappedByteBuffer VS FileChannel:从内核层面对比两者的性能差异

10
12