docker - Cloud Run - OpenBLAS 警告和应用程序重新启动（不是冷启动问题）

Question

问题

我有一个应用程序在Cloud Run实例上运行了 5 个月。该应用程序的启动时间约为 3 分钟，启动结束后，它不需要太多 RAM。这是我在本地运行应用程序时 docker stats 的两个快照：

当应用程序不兴奋时

当应用程序每秒接收 10 个请求时（目前这超出了我们的用例）：

当我在本地运行应用程序时没有任何问题，但是当我在 Cloud Run 上部署它时会出现问题。我不断收到：“OpenBLAS 警告 - 无法确定此系统上的 L2 缓存大小，假设为 256k”消息，然后重新启动应用程序。这是一个问题，因为正如我所说，应用程序最多需要 3 分钟才能重新启动，在此期间请求需要很长时间才能得到处理。

我已经通过使用 1 的最小实例并使用谷歌云调度程序每分钟查询一次服务来解决冷启动问题。

例子

以下是我在日志中看到的示例。

在第二个示例中，警告在应用程序重新启动后再次出现，导致连续第二次重新启动，这种情况经常发生。另请注意，这些警告/重启不一定会在用户连接到应用程序时发生，但可能会在唯一的活动归因于 Google Cloud Scheduler 时发生

我尝试将分配的 RAM 和 CPU 增加到 4 个 CPU 和 4 Go 的 RAM（这是一个巨大的过度杀戮），但问题仍然存在。

21 年 2 月更新 截至 21 年 1 月 1 日，我们停止从我们的云运行服务中看到这种行为（也许是由于更新，我不知道）。我确实联系了 GCP 支持，但他们只是告诉我在 OpenBLAS github repo 上提出问题，但由于我无法重现该行为，所以我没有这样做。我会留下这个问题，因为我所做的一切都没有真正奏效。

标签： dockergoogle-cloud-platformgoogle-cloud-runopenblas

Answer 1

OpenBLAS 执行高性能计算优化，并且需要知道什么是 CPU 容量以将其自身调优。

但是，当您在 Cloud Run 上运行容器时，您会在沙盒 GVisor 中运行它，以提高在同一无服务器平台上运行的所有容器的安全性和隔离性。

此沙箱拦截低级内核调用并丢弃异常/危险的调用。我猜出于这个原因，OpenBLAS 无法确定 L2 缓存大小。在您的环境中，您没有此沙箱，您可以直接访问 CPU 信息。

为什么要重启？？这可能是 OpenBLAS 的问题或 Cloud Run 的问题（可疑的内核调用，杀死实例并重新启动它）。

我没有立即解决方案，因为我不知道 OpenBLAS。我对 Tensorflow Serving 有类似的行为，并且 tensorflow 提出了一个没有任何 CPU 优化的编译版本：效率较低但更便携，并且对不同的环境约束更具弹性。如果 OpenBLAS 存在类似的编译，那么测试它可能会很棒。