0

前几天，我们的节奏设置遇到了一些问题。我们的一个机器实例开始将 CPU 使用率增加到 90%，并且所有入站工作流执行都停留在“已调度”状态。检查日志后，我们注意到匹配服务抛出以下错误：

{
  "level": "error",
  "ts": "2021-03-20T14:41:55.130Z",
  "msg": "Operation failed with internal error.",
  "service": "cadence-matching",
  "error": "InternalServiceError{Message: UpdateTaskList operation failed. Error: gocql: no hosts available in the pool}",
  "metric-scope": 34,
  "logging-call-at": "persistenceMetricClients.go:872",
  "stacktrace": "github.com/uber/cadence/common/log/loggerimpl.(*loggerImpl).Error\n\t/cadence/common/log/loggerimpl/logger.go:134\ngithub.com/uber/cadence/common/persistence.(*taskPersistenceClient).updateErrorMetric\n\t/cadence/common/persistence/persistenceMetricClients.go:872\ngithub.com/uber/cadence/common/persistence.(*taskPersistenceClient).UpdateTaskList\n\t/cadence/common/persistence/persistenceMetricClients.go:855\ngithub.com/uber/cadence/service/matching.(*taskListDB).UpdateState\n\t/cadence/service/matching/db.go:103\ngithub.com/uber/cadence/service/matching.(*taskReader).persistAckLevel\n\t/cadence/service/matching/taskReader.go:277\ngithub.com/uber/cadence/service/matching.(*taskReader).getTasksPump\n\t/cadence/service/matching/taskReader.go:156"
}

重新启动工作流程后，一切都恢复正常，但我们仍在试图弄清楚发生了什么。在这次活动的那一刻，我们并没有提出任何繁重的工作，它只是突然发生的。我们的主要怀疑是，匹配服务可能在此事件期间失去了与 cassandra 数据库的连接，而在我们重新启动它之后，它就能够恢复它。但这只是目前的一个假设。

这个问题的原因可能是什么？有没有办法防止这种情况在未来发生？也许我们错过了一些动态配置？

PS：Cadence版本为0.18.3

4

1 回答 1

0

这是 gocql 中的一个已知问题，可能由多种原因引起：

  1. Cassandra 过载，一些节点没有响应。您可能认为您的负载很小，但最好的查看方法是通过 Cadence 指标/仪表板。有一节是关于持久性指标的。
  2. 如果 1. 是问题所在，您可以调整速率限制以保护您的 Cassandra。使用matching.persistenceGlobalMaxQPS将充当全局速率限制器来覆盖matching.persistenceMaxQPS
  3. 网络问题或 gocql 中的一些错误。真是令人沮丧。我们最近决定在这个PR中进行刷新。希望这将在下一个版本中得到缓解。

此外，如果匹配的节点正在热运行，则可能您正在达到单个任务列表的限制。如果是这样，请考虑启用可扩展的任务列表功能。

于 2021-03-23T03:38:45.270 回答