如何在Cadence中增加持久性QPS限制

Question

Cadence中QPS极限有两种类型的错误

Persistence Max QPS Reached

和

Persistence Max QPS Reached for List Operations

最好的解决方法是什么？

Answer 1

它们用于保护数据库免受Cadence服务的过载。

持久性最大 QPS 在达到默认数据库上所有数据库操作的限制时达到。

默认数据库几乎是数据库操作的一切，包括插入/更新/删除工作流/活动。

当达到可见性数据库上仅db操作的限制时，持久性最大QPS已达到列表操作。如果使用高级可见性，可见性数据库可以是SQL/Cassandra或ElasticSearch。

可见性数据库仅用于提供可见性功能。

有不同的配置控制限制:

frontend.persistenceMaxQPS和frontend.persistenceGlobalMaxQPS共同控制前端服务的常规数据库操作的限制。默认值为每个节点2000。

匹配。persistenceMaxQPS和匹配。persistenceGlobalMaxQPS共同控制匹配服务的常规数据库操作限制。默认值为每个节点3000个。

history.persistenceMaxQPS和history.persistenceGlobalMaxQPS共同控制历史服务的常规数据库操作的限制。默认值为每个节点9000。

持久性最大QPS是单个节点的本地限制，而 XXX.持久性全球最大QPS是所有节点的全局限制。持久性全局最大 QPS 在设置为大于零时首选。

默认情况下为XXX。persistenceGlobalMaxQPS为零，因此使用persistence MaxQPS作为节点中的本地限制。检查文档中的默认值。

只有前端和历史服务需要查询可见性数据库：

frontend.visibilityListMaxQPS是基于cassandra/SQL数据库的前端服务可见性的本地节点限制。默认为10。(在旧版本中，它是1)

frontend . esvisibilitylistmaxqps是基于ElasticSearch的高级可见性的本地节点限制。默认为30。

历史historyVisibilityOpenMaxQPS是后台任务写入打开执行时，基于cassandra/SQL数据库的历史服务可见性的本地节点限制。后台任务应该能够进行退避重试，因此您不需要担心错误。

history . historyvisibilityclosedmaxqps与上面类似，但是写入封闭的表中。

首先，确定哪个服务有错误。例如：

"level":"error","ts":"2020-04-15T05:24:22.075Z","msg":"Error refreshing domain cache","service":"cadence-frontend","error":"ServiceBusyError{Message: Persistence Max QPS Reached.}","logging-call-...
...

这是在默认数据库操作上遇到 QPS 限制的前端服务。

但是，如果您看到：

"service":"cadence-frontend","error":"ServiceBusyError{Message: Persistence Max QPS Reached for List Operations.}"

然后是前端服务对可见性db操作的QPS限制（基于sql/Cassandra或ElasticSearch）。

因为默认限制是本地节点限制，所以提高限制的最简单方法是简单地向有错误的服务添加更多节点。对于我们上面提到的两个例子，您只需向前端服务添加节点就应该提高限制。

但理想情况下，您应该能够更改配置。它是通过动态配置部分。

这是动态配置格式。

如果您使用舵图，动态配置在此定义。举个例子，

frontend.persistenceGlobalMaxQPS:
  - value: 1000

将为默认db操作的所有前端服务设置全局限制。

frontend.visibilityListMaxQPS:
  - value: 100
frontend.esVisibilityListMaxQPS:
  - value: 100

将为可视性数据库操作(SQL/Cassandra或ElasticSearch)的所有前端服务设置全局限制。

提高限制后，请观察数据库的负载是否增加，以了解延迟和 CPU/内存。并根据需要扩展数据库。