部署到 AWS 时，gunicorn 上的 CRITICAL Worker TIMEOUT答案

【问题标题】：CRITICAL WORKER TIMEOUT on gunicorn when deployed to AWS部署到 AWS 时，gunicorn 上的 CRITICAL Worker TIMEOUT
【发布时间】：2020-01-07 08:49:01
【问题描述】：

我有一个使用 gunicorn 服务器的烧瓶网络应用程序，并且我使用了 gevent 工作程序类，因为它以前帮助我以前没有遇到 [CRITICAL] WORKER TIMEOUT 问题，但由于我已将它部署到 ELB 后面的 AWS 上，我似乎再次遇到这个问题。

我之前尝试过 eventlet 工人阶级，但没有用，但 gevent 在本地可以

这是我用作 Dockerfile 入口点的 shell 脚本：

gunicorn -b 0.0.0.0:5000 --worker-class=gevent --worker-connections 1000 --timeout 60 --keep-alive 20 dataclone_controller:app

当我检查 pod 上的日志时，这是唯一打印出来的信息：

[2019-09-04 11:36:12 +0000] [8] [INFO] Starting gunicorn 19.9.0
   [2019-09-04 11:36:12 +0000] [8] [INFO] Listening at: 
   http://0.0.0.0:5000 (8)
   [2019-09-04 11:36:12 +0000] [8] [INFO] Using worker: gevent
   [2019-09-04 11:36:12 +0000] [11] [INFO] Booting worker with pid: 11
   [2019-09-04 11:38:15 +0000] [8] [CRITICAL] WORKER TIMEOUT (pid:11)

【问题讨论】：

现在得到这个问题......你设法弄清楚了吗？
你能用--log-level debug 运行gunicorn 吗？
您确定 60 秒足够您的工作人员执行的操作吗？您是否尝试过增加超时时间？

标签： python amazon-web-services flask dockerfile gunicorn

【解决方案1】：

对于我们的 Django 应用程序，我们最终将其归结为内存耗尽。这很难追踪，因为 AWS 监控不提供内存统计信息（至少在默认情况下），即使提供了，也不清楚看到瞬时峰值有多容易。

其他症状包括：

此时我们经常会失去与 VM 的网络连接。
/var/log/syslog 包含一些进程重启的证据（在我们的例子中，这主要是 Hashicorp 的 Consul）。
没有证据表明 Linux OOM 检测起作用。
我们知道系统很忙，因为 AWS CPU 统计数据经常会显示峰值（比如 60%）。

我们的解决办法是明智地转换 Django 查询，看起来像这样：

   for item in qs:
       do_something()

像这样使用.iterator()：

CHUNK_SIZE = 5
...
   for item in qs.iterator(CHUNK_SIZE):
       do_something()

有效地交换数据库往返以降低内存使用量。请注意，CHUNK_SIZE = 5 是有意义的，因为我们正在使用 JSONB 的 big 列获取一些数据库对象。我预计更典型的用法可能会使用大几个数量级的数字。

【讨论】：

宾果游戏！内存耗尽。谢谢。