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