部署到 AWS 时，gunicorn 上的关键工作人员超时

Question

我有一个使用 gunicorn 服务器的 Flask Web 应用程序，并且我使用了 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)

Answer 1

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

其他症状包括：

• 此时我们经常会失去与虚拟机的网络连接。
• /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 列的数据库对象。我预计更典型的用法可能会使用大几个数量级的数字。