问题回顾
测试通过包回放技术压测一晚上，发现kafka堆积。我登上服务器排查发现每秒吞吐率仅3k左右，问了一下测试，1u8核心16g预期吞吐率为5-6k，压测85兆不堆积。
/capaa/kafka/bin/kafka-consumer-groups.sh --command-config=/capaa/kafka/config/kraft/sasl.properties --bootstrap-server 127.0.0.1:9092 --describe --all-groups | grep access
使用工具
压测工具
通过tcpreplay回放tcp包的形式。
tcpreplay -i mc2 -M 85 -l 20000000000000000 /data/sql/scene3_merge.pcap &
函数级性能排查工具
trace com.hzmc.epc.plugin.staccount.cache.APIAccessExCache isAlert -n 5 --skipJDKMethod false
内存排查工具
jmap
jmap -dump:live,format=b,file=tomcat.hprof 5675
arthas 导出
可以通过arthas 导出在fullgc之前导出dump文件
vmoption HeapDumpBeforeFullGC true
gc排查工具
通过jstat 分析各种gc的耗时和数量
jstat -gcutil 5675 1000
arthas 全局火焰图排查工具
当无法通过阅读代码，定位到某个函数存在性能问题时，可以考虑使用arthas导出火焰图，分析全局的性能瓶颈。
profiler start --event cpu --include '*Filter'
profiler stop --file /tmp/result.html
总结和展望
一开始我的想法是，用arthas工具命trace命令,排查下耗时较大的函数。这种方法有效但是仅对耗时特别大的问题生效。比如字符串的equal和contains方法。修改这些后还是有系统压测100分钟还是有50w事件的堆积。另外同事也是使用arthas也发现了直接打印debug日志的问题。而没有首先判断是否开启debug日志再打印。改动上述两点后，继续压测未发现堆积问题，这里我留下了一个隐患，我把身份插件也还原到上一个版本。
后续测试压测验证时还是发现堆积，但是堆积没有那么明显。由于重心放在自己开发的代码和另一位同事自定义报表的功能上。尝试了使用各种方法导出trace 某些怀疑耗时的方法，但是没有发现特别耗时的问题。 ;使用mat导出dump文件，通过分析占比最多的类也没有收获;查看gc日志，发现ygc很多，而full gc 会一阵子多起来然后又降下去。都不能奏效。
通过arthas 导出全局性能火焰图排查工具发现IdentityConfig的实例化方法性能占比4%;查看下图38行代码发现，虽然使用了putIfAbsent 但是IdentityConfig对象还是会被实例化。而IdentityConfig是一个相对较重的类，每次实例化都需要new 一个caffeine 缓存。后续替包压测后没有堆积问题。
