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

Posted 2023-02-19

【中文标题】Cloud Run - OpenBLAS 警告和应用程序重启（不是冷启动问题）

【英文标题】：Cloud Run - OpenBLAS Warnings and application restarts (Not a cold start issue)

【发布时间】：2021-03-28 23:02:27

【问题描述】：

问题

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

当应用不兴奋时

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

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

我已经修复了cold start issue，方法是使用最小实例 1 并使用谷歌云调度程序每分钟查询一次服务。

示例

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

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

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

02/21 更新 自 21 年 1 月 1 日起，我们不再从我们的云运行服务中看到此类行为（可能是由于更新，我不知道）。我确实联系了 GCP 支持，但他们只是告诉我在 OpenBLAS github repo 上提出问题，但由于我无法重现该行为，所以我没有这样做。我会留下这个问题，因为我没有真正奏效。

【参考方案1】：

OpenBLAS 执行高性能计算优化，需要知道什么是 CPU 容量才能对其进行最佳调整。

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

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

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

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

【讨论】：

感谢您的回答。这似乎比我想象的更具技术性。您如何确定是 Tensorflow 导致了错误？我使用了许多不同的库，但我不知道哪一个可能是原因。

我有一个 GVisor 警告日志条目。我更改了 Tensorflow Serving 编译版本，GVisor 跟踪消失了，但由于硬件优化被禁用，我从 Tensorflow 获得了新跟踪。

好的，我会尝试找出导致它的原因，并希望继续这个线程。