Cadence基准测试出现cadence_matching客户端报错排查咨询

这个报错本质是Cadence的Matching服务调用History服务的RecordActivityTaskStarted接口失败/超时触发，在2台m5a.xlarge（4核16G）规格部署、未做任何动态配置调整的前提下，压测时出现这类报错基本集中在以下几类原因：

• 资源瓶颈：m5a.xlarge本身规格偏低，如果把Frontend、Matching、History服务角色，甚至Cassandra/MySQL这类持久化组件全混部在这2台节点上，压测流量上来很容易出现CPU长期打满、内存吃紧、磁盘IO wait飙升、网络带宽抢占的问题，直接导致History服务响应超时，Matching侧调用就会抛出对应错误。可先核对节点监控：CPU使用率长期超80%、磁盘IO wait高于10%、可用内存低于总内存10%的时候，首先判定是资源不足。
• 默认配置阈值不适配压测场景：Cadence出厂默认动态配置是面向低流量功能测试环境做的，几个关键参数的默认值在压测流量下很容易触发限流、超时：
  • Matching调用History的RPC默认超时仅1s，高负载下History请求排队就会触发超时
  • 单实例请求处理并发、轮询并发默认限制很低，流量稍高就会触发限流
  • 持久化层连接池大小、读写超时默认值偏小，高并发下数据库请求直接排队堵死
• 分片负载倾斜：Cadence History服务是按分片做负载分配的，2节点部署如果分片调度不均，单个节点扛了绝大多数分片流量，会出现单节点过载、另一节点闲置的情况，过载节点的请求就会大量失败。
• 网络层抢占：混部场景下数据同步、持久化读写、服务间RPC流量抢占网卡带宽，很容易出现RPC丢包、延迟陡增的问题。

必须补充动态配置，默认配置完全扛不住压测流量，几个核心必调项如下，初始值可以先按参考值设置，后续根据压测表现微调：

# 放大Matching调用History的RPC超时，默认1s无法适配压测场景，初始设为5s
system.matching.rpc.timeout: 5000
# 放大History单实例最大并发处理请求数，默认100很容易打满，初始设为1000
system.history.maxConcurrentRequests: 1000
# 放大Matching单实例最大并发轮询数，默认值偏低，初始设为500
system.matching.maxPollers: 500
# 放大持久化层连接池大小，默认连接数高并发下会直接耗尽，初始设为200
system.persistence.maxConns: 200
# 压测阶段先关掉服务端全局限流，避免误拦截压测流量
system.frontend.rps: 0
system.history.rps: 0
system.matching.rps: 0

注意：不要一开始就把参数拉到极高，避免参数过大导致服务OOM，每次调整后观察内存、CPU变化再逐步迭代。

• 先核基础资源监控：拉取2台EC2的CPU、内存、磁盘IO、网络带宽监控数据，先排除硬件资源瓶颈。如果是资源打满导致的问题，优先升配，或者把持久化组件、不同服务角色拆到独立节点部署，不要全混部。
• 查服务端错误日志：分别捞取Matching、History服务的error级别日志，重点匹配context deadline exceeded（RPC超时）、too many requests（触发限流）、connection reset/connection refused（网络连接异常）三类关键字，直接定位失败类型。
• 核对History分片分布：查监控指标cadence_history_shard_count，确认2个节点上的History分片数基本均等，如果出现单节点分片占比超70%的倾斜情况，触发分片重平衡即可。
• 做调用链路定位：如果开了Cadence内置的链路追踪，直接筛选RecordActivityTaskStarted接口的调用链，看耗时卡在哪一段：是History服务内部业务逻辑处理慢，还是持久化读写堵了，还是RPC网络传输耗时长。
• 梯度压测验证：配置调整完后从低流量开始逐步加压，每提升一次流量档位，同步观察错误率、接口P99延迟、资源使用率三个核心指标，找到集群实际性能拐点，不要一开始就打满流量。

补充提醒：2台m5a.xlarge的规格本身仅适合功能验证，正式压测建议至少把Cassandra/MySQL这类持久化组件单独部署，不要和Cadence核心服务混部，否则磁盘IO会成为非常明显的瓶颈。

内容的提问来源于stack exchange，提问作者Chandrakanth Ganji