gunicorn worker 为每个请求退出

Question

我全新安装了 apache-airflow 1.8.2，启动了它的网络服务器，它的 gunicorn worker 在每次网页请求时退出，让请求挂起大约 30 秒，同时等待新的 worker 产生。需要帮助解决此问题。

详情如下

我已经安装了 apache-airflow 1.8.2 并关注了 this guide。我在 8081.

端口启动了网络服务器

现在用浏览器访问服务器时，响应很慢。我查看了控制台输出，发现每次加载网页时，它都会显示 "Worker existing"，然后停顿很长时间并显示 "Booting worker".

挖源码后发现，这些都是gunicorn worker。我没有使用 gunicorn、airflow 或 Flask 的经验，所以我不知道这是否是预期的行为，但我觉得不应该。至少网络服务器不应该为每个网页挂起半分钟。

控制台输出：

---> Browser request
[2017-11-01 19:08:07 -0700] [14549] [INFO] Worker exiting (pid: 14549)
---> Hangs for 30s
[2017-11-01 19:08:37 -0700] [13316] [INFO] Handling signal: ttin
[2017-11-01 19:08:37 -0700] [14698] [INFO] Booting worker with pid: 14698
/Users/michael/Programs/clones/airflow/airflow/www/app.py:23: FlaskWTFDeprecationWarning: "flask_wtf.CsrfProtect" has been renamed to "CSRFProtect" and will be removed in 1.0.
  csrf = CsrfProtect()
/Users/michael/Programs/miaozhen/tests/airflow-test/lib/python3.6/site-packages/flask/exthook.py:71: ExtDeprecationWarning: Importing flask.ext.cache is deprecated, use flask_cache instead.
  .format(x=modname), ExtDeprecationWarning
127.0.0.1 - - [01/Nov/2017:19:08:37 -0700] "GET /admin/ HTTP/1.1" 200 95063 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36"
[2017-11-01 19:08:38,096] [14698] {models.py:168} INFO - Filling up the DagBag from /Users/michael/airflow/dags
---> other GET requests on the same webpage, skipped here for simplicity
[2017-11-01 19:08:39 -0700] [13316] [INFO] Handling signal: ttou

现在我是运行 apache-airflow 1.8.2 的源代码版本（即克隆源代码，检查标签，并使用 pip install -e . 安装）在 virtualenv .但是我也尝试过：运行没有 virtualenv 的 pypi 版本 (pip install apache-airflow)；运行没有 virtualenv 的源版本。所有安装都存在相同的问题，因此这些差异无关紧要。

我的 Python 安装是：

$ python -VV
Python 3.6.3 (default, Oct  4 2017, 06:09:38) 
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]

编辑：

我试过在另一台机器上安装&运行apache-airflow（UbuntuLinux16.04+Python3.5），没有问题。我也问了另外一个用Python3.6上Mac的人，也没有问题。我想我的机器有些奇怪...有什么建议可以调试这个东西吗？

Answer 1

工人定期退出信号ttou（意思是decrement # of processes by one) every so often is intentional. This is airflow periodically "refreshing" workers. Based on what I read in AIRFLOW-276，它增加了这个功能，刷新工人是为了确保他们接受新的或更新的DAGs。这个行为可以在你的气流中修改在 worker_refresh_interval 和 worker_refresh_batch_size 下配置。

从 source 来看，它会在停止旧工作程序之前启动新工作程序，所以我认为这不会导致您的请求延迟。但是，您可以尝试使用 worker_refresh_batch_size = 0.

禁用它

Answer 2

好的，在调试源代码后我设法隔离了问题，但是它与 gunicorn 无关。

问题是this

$ time python -c 'import socket; socket.getfqdn()'

real    0m30.051s
user    0m0.018s
sys     0m0.013s

我认为这个问题应该关闭，因为它现在无效，但我不知道该怎么做。

Answer 3

我运行遇到了与气流 1.10.1 相同的问题，WUI 非常没有响应，果然，对 socker.getfqdn() 的调用需要 10 秒。

我运行正在使用旧版本的 Docker，众所周知，当容器试图通过 DNS 解析自己的地址时，它会遇到问题。

作为解决方法，我将 airflow.cfg 中的配置值 hostname_callable 更改为 socket:gethostname，并且 WUI 证明响应。

这确实意味着所有日志中使用的主机名将是本地主机名（即您在运行 hostname 时获得的主机名）。

gunicorn worker 为每个请求退出

gunicorn worker exits for every request

python

gunicorn

airflow

apache-airflow

详情如下