Azure上的Flask API部署因容器超时而无法启动（2GB模型大小）

Question

我正在 Azure 应用服务（高级 V3 P2V3 计划）上通过本地 git 部署 Flask API，模型大小约为 2 GB。但是，我在启动过程中在日志中遇到以下错误：

2024-12-10T12:06:33.635Z ERROR - Container tdoc3_0_bded436f for site tdoc3 did not start within expected time limit. Elapsed time = 230.5782541 sec
2024-12-10T12:06:33.651Z ERROR - Container tdoc3_0_bded436f didn't respond to HTTP pings on port: 8000, failing site start. See container logs for debugging.
2024-12-10T12:06:33.658Z INFO  - Stopping site tdoc3 because it failed during startup.

apt-get update && apt-get install -y \
    libmagic1 \
    build-essential \
    python3-dev \
    libjpeg-dev \
    libmupdf-dev \
    mupdf-tools \
    tesseract-ocr \
    poppler-utils \
    libgl1-mesa-glx \
    libglib2.0-0 \
    libopencv-dev && \
    gunicorn --workers 3 --bind 0.0.0.0:8000 --timeout 700 --log-level debug app:app

详情：

计划：高级 V3 P2V3 模型大小：~2 GB 使用gunicorn设置Flask API 在端口 8000 上运行 我收到容器超时错误，并且应用程序不响应 HTTP ping。

我尝试过的：

增加了gunicorn命令中的超时值（--timeout 700）。 确保容器中安装了所有必需的依赖项。

问题：

Azure 应用服务对于大型模型或依赖项的容器启动时间是否存在已知限制？ 2GB 模型大小是否会导致超时？如果是这样，我如何优化我的应用程序或模型加载以避免此问题？ 我需要在 Azure 应用服务中更改任何配置（例如，增加启动超时、调整内存设置）以适应更大的模型大小吗？

附加信息：

Azure Premium V3 P2V3 计划（资源绰绰有余）。 日志表明容器未能在预期时间内响应。 任何有关此问题的指导将不胜感激！

Answer 1

2024-12-10T12:06:33.635Z 错误 - 站点 tdoc3 的容器 tdoc3_0_bded436f 未在预期时间限制内启动。经过的时间 = 230.5782541 秒

您遇到的错误是由于较长的依赖项安装和较大的模型大小导致启动超过允许的超时。

• 要解决此问题，请将依赖项安装移出

  startup.sh

  脚本。
• 您可以使用应用服务构建脚本将它们预安装在应用服务运行时中。
• 运行以下命令在 Azure 应用服务 Kudu 控制台中安装依赖项。

apt-get update
apt-get install -y libmagic1 build-essential python3-dev libjpeg-dev libmupdf-dev mupdf-tools tesseract-ocr libtesseract-dev poppler-utils libgl1-mesa-glx libglib2.0-0 libopencv-dev libatlas-base-dev libopenjp2-7 libtiff5

转到 Azure Web 应用程序的 kudu 控制台 -> SSH 并运行所示命令。

现在安装了依赖项，您可以删除依赖项并修改

startup.sh

脚本以仅专注于运行应用程序。

最终启动.sh：

gunicorn --workers 3 --bind 0.0.0.0:8000 --timeout 1800 --log-level debug app:app

由于您的模型大小为 2 GB，可能会导致延迟，因此您可以将模型上传到 Azure Blob 存储。

请参阅此doc，以更好地了解如何管理 Azure Blob 存储中的文件。

如果问题仍然存在，请尝试使用 Azure Kubernetes 服务 (AKS) 或 Azure 容器实例 (ACI) 以获得更好的资源控制并避免启动时间限制。