使用async-profiler简单分析zeebe 工作流引擎的性能

刚开始的时候直接使用的系统暴露的prometheus metrics，发现越高的版本反而性能越差，期间使用过了
perf 打算使用perf 生成火焰图的，但是因为符号缺失，只找到了占用较高的任务，详细的暂时没有取到
以前大概知道一个工具perf-map-agent 可以用来生成缺失的符号，但是只是不太好，发现了async-profiler
工具，使用方便，支持的版本都，同时也支持基于容器的部署模型，但是容器运行暂时有点问题，所以直接
使用虚拟机运行，配置的分片为1，副本也为1

使用async-profiler 获取指标

 
./profiler.sh -d 120 -o collapsed -f more8 `pid of java`
 
./FlameGraph/flamegraph.pl more8 > flamegraph8.svg
  • 效果

发现大部分的占用都是raft 的读

 

 

几个问题

  • 实际看到磁盘写很大

从火焰图我们可以看出读取占用较多的时间，但是检测磁盘的话，我们发现磁盘写很大，可选的排查工具iostat 以及使用async-profiler
使用iostat 我们发现写是偶然的很大，基本都在20M左右，和我们实际看到的情况一致
使用async-profiler 可以使用tree 模式 ./profiler.sh -d 30 -t -o flat,tree -f zeebe-demo.txt pid of java 我们会发现有写，但是占用的cpu
时间并不高，如下：

 

 

  • 分区与线程的关系

官方有一个介绍是关于分区数与线程的关系，一个分区占用2个线程，和我们看到的raft-server-raft-atomix-partition 任务一致
比如下边的为4个分区的，从界面看到大概有两类，后边再看看atomix 的原理（zeebe 状态维护的底层依赖）

 

 

目前的几个结论

  • zeebe 目前版本还不太稳定
    但是0.21.1 版本比以前的版本稳定
  • zeebe 分区个数会严重影响系统性能
    cpu 核数，磁盘io，以及集群规模都会都系统的响应有很大的影响，推荐部署使用ssd
  • exporter 对于系统有影响，但是并不大
    在测试的过程中，为了简单exporter 的影响，删除了对于es exporter的配置，对于系统响应并不提大（通过prometheus metrics 查看）
  • 后边还是研究下atomix 的实现原理以及优化（zeebe 强依赖）

参考资料

一个简单的基于docker-compose 的基础环境https://github.com/rongfengliang/zeebe-debughttp-exporter-demo 实际运行结合场景
修改下配置
https://docs.zeebe.io/basics/partitions.html
https://github.com/jvm-profiling-tools/async-profiler
https://github.com/brendangregg/FlameGraph
https://github.com/atomix/atomix
https://github.com/Netflix/flamescope

posted on 2019-12-12 10:41  荣锋亮  阅读(1362)  评论(0)  编辑  收藏  举报

导航