一个针对高并发、低延迟应用设计的高性能 Java 性能监控和统计工具。
特性
- 高性能: 单线程支持每秒 1000 万次 响应时间的记录,每次记录只花费 73 纳秒
- 无侵入: 采用 JavaAgent 方式,对应用程序完全无侵入,无需修改应用代码
- 低内存: 采用内存复用的方式,整个生命周期只产生极少的临时对象,不影响应用程序的 GC
- 高精度: 采用纳秒来计算响应时间
- 高实时: 支持秒级监控,最低 1 秒
使用场景
- 在开发环境中快速定位 Java 应用程序的性能瓶颈
- 在生产环境中长期监控 Java 应用程序的性能指标
文档
- English Doc
- 中文文档
监控指标
MyPerf4J 为每个应用收集数十个监控指标,所有的监控指标都是实时采集和展现的。
下面是 MyPerf4J 目前支持的监控指标列表:
- Method Metrics
- RPS,Count,Avg,Min,Max,StdDev,TP50, TP90, TP95, TP99, TP999, TP9999, TP99999, TP100
- JVM Metrics
- Thread,Memory,ByteBuff,GC,Class
想知道如何实现上述效果?请先按照快速启动的描述启动应用,再按照这里的描述进行安装配置即可。
快速启动
MyPerf4J 采用 JavaAgent 配置方式,透明化接入应用,对应用代码完全没有侵入。
打包
- git clone git@github.com:LinShunKang/MyPerf4J.git
- mvn clean package
- 把 MyPerf4J-ASM-${MyPerf4J-version}.jar 重命名为 MyPerf4J-ASM.jar
可以尝试直接下载 MyPerf4J-ASM.jar
配置
在 JVM 启动参数里加上以下两个参数
- -javaagent:/your/path/to/MyPerf4J-ASM.jar
- -DMyPerf4JPropFile=/your/path/to/myPerf4J.properties
形如:java -javaagent:/your/path/to/MyPerf4J-ASM.jar -DMyPerf4JPropFile=/your/path/to/myPerf4J.properties -jar yourJar.jar
注意:使用 Windows 的同学,请注意修改路径格式,包括 MyPerf4JPropFile 中的文件路径
其中,MyPerf4JPropFile的配置如下:
#应用名称AppName=MyPerf4JTest#MetricsProcessor类型,0:以标准格式化结构输出到stdout.log 1:以标准格式化结构输出到磁盘 2:以InfluxDB LineProtocol格式输出到磁盘MetricsProcessorType=1#配置各个Metrics日志的文件路径,可不配置MethodMetricsFile=/data/logs/MyPerf4J/method_metrics.logClassMetricsFile=/data/logs/MyPerf4J/class_metrics.logGCMetricsFile=/data/logs/MyPerf4J/gc_metrics.logMemMetricsFile=/data/logs/MyPerf4J/memory_metrics.logBufPoolMetricsFile=/data/logs/MyPerf4J/buf_pool_metricsThreadMetricsFile=/data/logs/MyPerf4J/thread_metrics.log#配置Record模式,可配置为accurate/roughRecorderMode=accurate #配置时间片,单位为ms,最小1s,最大600sMilliTimeSlice=10000 #需要监控的package,可配置多个,用英文';'分隔IncludePackages=cn.perf4j.demo;cn.perf4j.demo1.[p1,p2,p3];cn.*.demo.*#是否展示方法参数类型ShowMethodParams=true
查看配置文件模板。想了解更多的配置?请看这里
运行
- 输出结果,输出到 /data/logs/MyPerf4J/method_metrics.log:
MyPerf4J Method Metrics [2019-03-03 17:27:50, 2019-03-03 17:28:00]Method[5] Type RPS Avg(ms) Min(ms) Max(ms) StdDev Count TP50 TP90 TP95 TP99 TP999 TP9999 TP99999 TP100DemoServiceImpl.getId1(long) General 51317 0.00 0 1 0.00 513178 0 1 1 1 1 1 1 1DemoServiceImpl.getId2(long) General 168637 0.00 0 4 0.00 1686377 0 1 2 3 4 4 4 4DemoServiceImplV2.getId1(long) General 357 0.00 0 0 0.00 3570 0 0 0 0 0 0 0 0DemoServiceImplV2.getId3(long) General 713 0.51 0 5 0.08 7138 0 1 2 3 4 5 5 5Dao.doQuery() DynamicProxy 1394 0.51 0 5 0.05 13944 0 1 2 3 4 5 5 5
整体架构
详情请参考 这里
数据采集
MyPerf4J 目前采用 ASM 字节码修改框架在 JVM 加载类时修改 Java 方法的字节码:
- 在方法的开头加入 long start = System.nanoTime();
- 在方法的结尾加入 ProfilingAspect.profiling(start, methodId);,其中 methodId 为类加载时为每一个方法分配的唯一 ID
想了解 ASM?请下载 ASM4使用指南.pdf
数据存储
MyPerf4J 采用 数组(timingArr) + Map(timingMap) 的方式存储方法的响应时间:
- 在 timingArr 中,数组下标代表方法的响应时间,而下标对应的元素值代表该响应时间出现的次数,例如从上图中可以看出,timingArr 中记录了 100次 0ms 的响应,0次 1ms 的响应,80次 2ms 的响应 和 20次 3ms 的响应
- 在 timingMap 中,Map 的 key 代表方法的响应时间,而 key 对应的 value 代表该响应时间出现的次数,例如,从上图中可以看出,timingMap 中记录了 120次 1010ms 的响应,102次 1025ms 的响应,95次 1041ms 的响应,1次 2094ms 的响应
MyPerf4J 内存占用分析:
假设你有 1024 个方法需要监控,并且 timingArr 长度为 3000,timingMap 大小为 128,Recorders 转盘的数量为 3
- 每个 timingArr 占用 3000 * 4B = 12KB 的空间
- 每个 timingMap 占用的空间为 128 * 64B = 8KB,其中,每个 Map.Node 占用 64B(32B + 16B + 16B) 综上所述,监控这 1024 个方法只需要占用 3 * 1024 * (12KB + 8KB) = 60MB,并且这 60MB 的对象常驻在内存中,除了 timingMap 扩容和缩容时会分配少量内存外,所有的对象在 MyPerf4J 的整个生命周期中只分配一次!
数据处理
为简化处理流程,以 timingArr 为例进行说明:
- 第一步,通过遍历一次 timingArr 可以计算出所有响应时间及其出现的次数,把这份数据存入 sortedRecords 中,在 sortedRecords 偶数下标代表响应时间,奇数下标代表次数,以上图为例,0ms 出现 100次,2ms 出现 80次,3ms 出现 20次
- 第二步,把 sortedRecords 按逻辑展开,即可快速计算出 TP50、TP90 和 TP99 等指标,以上图为例,把 sortedRecords 按逻辑展开,可以得到连续存放的 100 个 0、80 个 2 和 20 个 3,一共 200 个响应时间,那么 TP50 对应于下标为 200 * 50% = 100 的值,也就是 2ms