我正在使用托管 CloudRun 部署具有 concurrency=1 的容器。部署后，我将并行触发四个长时间运行的请求。大多数时候，一切正常 - 但偶尔，我在几秒钟内面对来自其中一个节点的 500;日志仅提供主题中提供的错误消息。
使用具有指数退避的重试并没有改善这种情况;重试也以 500 秒结束。 StackDriver 日志也不会提供更多信息。
可能相关的gcloud beta run deploy论点：
--memory 2Gi --concurrency 1 --timeout 8m --platform managed
错误消息的确切含义是什么 - 我该如何解决问题？
当基础结构的扩展速度不够快以赶上流量峰值时，可能会出现此错误消息。基础结构仅在队列中保留请求一段时间(大约 10 秒(，然后中止它。
这通常发生在以下情况下：
- 流量突然大幅增加
- 冷启动时间长
- 请求时间长
当流量在工作时间突然增加时，我们也遇到了这个问题。该问题通常是由流量突然增加和更长的实例启动时间来容纳传入请求引起的。处理此问题的一种方法是保持预热实例始终运行，即在云运行部署命令中配置 --min-instances 参数。另一种推荐的方法是减少服务冷启动时间(这在某些语言中很难实现，如Java和Python(
我也尝试了这个问题。易于复制。我有一个斐波那契容器，在 6s 斐波那契(45( 中处理。我使用 Hey 执行 200 个请求。我将云运行并发设置为 1。
超过 200 个请求，我有 8 个类似的错误。就我而言：突然的流量高峰和较长的处理时间。(对我来说短暂的冷启动，它在围棋中(
我能够通过将最大自动缩放容器计数从 2 增加到 10 来在我的服务上解决此问题。真的没有理由认为 2 对于流量来说甚至太低了，但我怀疑 Cloud Run 内部的某些东西以某种方式绑定了 2 个容器。
将Max Retry Attempts设置为零以外的任何值将解决此问题，就像它对我所做的那样。
此错误可能是由以下原因之一引起的。
- 流量突然大幅增加。
- 较长的冷启动时间。
- 请求处理时间长
- 请求处理时间突然增加
- 服务达到其最大容器实例限制 (HTTP 429(
我们偶尔遇到类似的问题，这是由于请求处理时间长，而数据库延迟对于少数请求来说很高。