刚开始的时候直接使用的系统暴露的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
  生成火焰图命令

./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 强依赖）