所以我遇到的问题是，一个正在运行flask API的应用引擎实例陷入了无休止的工人重新启动的循环，并且一直没有响应，这促使应用引擎扩大规模并添加实例(最多20个！(。
烧瓶API提供多个机器学习模型，这些模型必须逐个加载。装载其中一个模型显然花了很长时间，导致工人被解雇。日志基本上显示了这一点：
A 2020-03-20T14:42:23Z [2020-03-20 14:42:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:2952)
A 2020-03-20T14:42:23Z [2020-03-20 14:42:23 +0000] [2952] [INFO] Worker exiting (pid: 2952)
A 2020-03-20T14:42:24Z [2020-03-20 14:42:24 +0000] [2975] [INFO] Booting worker with pid: 2975
在app.yaml中更改这些设置没有任何效果，因为它们在更高的级别上：
liveness_check:
initial_delay_sec: 300
check_interval_sec: 30
timeout_sec: 4
failure_threshold: 4
success_threshold: 2
readiness_check:
check_interval_sec: 5
timeout_sec: 4
failure_threshold: 2
success_threshold: 2
app_start_timeout_sec: 300
您应该为无限超时设置--timeout 0。
当应用引擎缩减实例并认为工作人员超时时，gunicorn仲裁者会感到困惑。
App Engine有自己的主管来监督超时(超时时间要长得多(，因此Gunicorn没有必要处理工作人员超时。
快速搜索后，似乎更有可能是持枪工人跑进了雾中。我发现这些文档允许我设置以秒为单位的超时时间。
瞧。在我的app.yaml文件中，我添加了-t 75，并能够解决这个问题。事实证明，其中一个旧模型——一个大的Naive Bayes分类器——需要大约50年代才能加载。
我的应用程序：
entrypoint: gunicorn -b :$PORT main:app -t 75
我看到有些人在应用程序引擎上运行flask API，在某些变体中也遇到了这个问题，所以我想我应该提供这个额外的面包屑。