【问题标题】:Nginx non-responsive while celery is runningcelery 运行时 Nginx 无响应
【发布时间】:2017-06-17 14:22:33
【问题描述】:

我有一个 django 应用程序配置为使用 uWSGI 在 nginx 后面运行。在另一台机器上,我正在运行 celery,并将长时间运行的任务从网络服务器推送到任务机器。大部分任务 I/O 是出站 http 请求,这些请求会持续一个小时或更长时间。任务代理是redis。

当任务运行超过一两分钟时,网络服务器变得无响应(503 错误)。

python 应用程序中的任何地方都没有出现错误。任务正常完成,之后网络服务器继续处理请求。

以前有没有人经历过这种情况,如果有,您是如何处理的?谢谢

【问题讨论】:

    标签: python django nginx redis wsgi


    【解决方案1】:

    几天后想通了。我们正在使用一个名为 django-health-check 的 django 应用程序。它有一个名为 health_check_celery3 的组件,位于已安装的应用程序中。这在 celery 运行时加载有问题,从而导致整个应用程序停止。删除后,celery 运行正常。

    【讨论】:

      【解决方案2】:

      默认情况下 uWSGI 以单个进程和单个线程开始

      来自uwsgi docs。根据您的配置,这可能会导致问题。

      更新:刚刚注意到您没有说 uwsgi,而只是说 wsgi - 但是根据您的 wsgi 实现,问题可能是由相同的事实引起的。

      【讨论】:

      • 对不起,确实是uWSGI(上面编辑过)。我们已将其配置为多处理。即使我们没有,我也不明白为什么单线程 Web 应用程序会在调用 celery 任务后阻塞。或者为什么阻塞不会立即发生,而是在几分钟后发生。
      • 这是否适用:nginx uwsgi django 盒子是任务机器,来自 celery 的 http 请求命中了这个任务机器?还是这两个盒子redis之间的唯一联系,它们之间没有别的关系?
      • 两个盒子只通过redis连接。还有一个共享的 postgres 数据库,但它存在于另一个盒子上,而且似乎没有一个人在维护 db 连接时遇到问题。
      猜你喜欢
      • 1970-01-01
      • 2017-01-24
      • 1970-01-01
      • 2021-08-07
      • 1970-01-01
      • 1970-01-01
      • 2015-10-24
      • 2021-04-08
      • 1970-01-01
      相关资源
      最近更新 更多