Gunicorn: Gunicorn 同步工作人员在 docker + AWS 上超时

hrmmm 从上面的日志中我可以看到时间永远不会改变。 我会查的

谢谢，我很感激！

我可能会受到这个错误的影响。

我在 AWS（Elastic Beanstalk + EC2 容器服务）上的 Docker 映像中运行 gunicorn。
初始化后几乎立即开始发生持续的工作超时，并且仅在 AWS 上运行 Docker 映像时才会发生。
相同的 HTTP 请求有时需要几毫秒，有时需要 20-30 秒。 无论是针对不存在的页面、简单的未经身份验证的“Hello world”字符串页面还是从数据库获取记录的页面都无关紧要。

其他细节：

• Gunicorn版本：19.5.0 和 19.6.0。
• 基本 Docker 映像： python:3.4 （操作系统：Debian Jessie）
• Docker 版本：1.9.1（由 Amazon ECS 管理），操作系统：Amazon Linux AMI 2016.03（由 Amazon EB 管理）。
• Web 应用程序框架：Django 版本 1.9.6 和 1.9.7。

_未_影响的环境：

• 本地机器，包括 _inside_ 和 _outside_ Docker 容器。 操作系统：Ubuntu 16.04 LTS， Docker ：1.11.2。
• Heroku （操作系统：Ubuntu 14.04 LTS）

亚马逊容器日志：

[2016-06-15 16:46:15 +0000] [1] [DEBUG] Current configuration:
  cert_reqs: 0
  post_request: <function PostRequest.post_request at 0x7fb13e187c80>
  worker_connections: 1000
  tmp_upload_dir: None
  enable_stdio_inheritance: False
  timeout: 30
  pre_fork: <function Prefork.pre_fork at 0x7fb13e1871e0>
  worker_int: <function WorkerInt.worker_int at 0x7fb13e1876a8>
  backlog: 2048
  max_requests: 0
  max_requests_jitter: 0
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  logconfig: None
  syslog_addr: udp://localhost:514
  preload_app: False
  pidfile: None
  umask: 0
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  paste: None
  proxy_protocol: False
  worker_class: sync
  on_starting: <function OnStarting.on_starting at 0x7fb13e414c80>
  worker_abort: <function WorkerAbort.worker_abort at 0x7fb13e187840>
  worker_exit: <function WorkerExit.worker_exit at 0x7fb13e187e18>
  config: config/gunicorn.py
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7fb13e18a048>
  daemon: False
  accesslog: None
  errorlog: -
  loglevel: debug
  syslog_prefix: None
  ssl_version: 3
  suppress_ragged_eofs: True
  limit_request_field_size: 8190
  reload: False
  logger_class: gunicorn.glogging.Logger
  statsd_host: None
  keyfile: None
  raw_env: []
  threads: 1
  django_settings: None
  proc_name: None
  proxy_allow_ips: ['127.0.0.1']
  limit_request_fields: 100
  ciphers: TLSv1
  check_config: False
  do_handshake_on_connect: False
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7fb13e187510>
  graceful_timeout: 30
  worker_tmp_dir: None
  certfile: None
  sendfile: None
  keepalive: 2
  chdir: /app/testapp
  when_ready: <function WhenReady.when_ready at 0x7fb13e187048>
  ca_certs: None
  on_exit: <function OnExit.on_exit at 0x7fb13e18a1e0>
  spew: False
  bind: [':8000']
  post_fork: <function Postfork.post_fork at 0x7fb13e187378>
  limit_request_line: 4094
  syslog_facility: user
  workers: 3
  syslog: False
  pre_request: <function PreRequest.pre_request at 0x7fb13e187b70>
  user: 0
  group: 0
  forwarded_allow_ips: ['127.0.0.1']
  pythonpath: None
  on_reload: <function OnReload.on_reload at 0x7fb13e414e18>
  pre_exec: <function PreExec.pre_exec at 0x7fb13e1879d8>
  default_proc_name: config.wsgi
  statsd_prefix: 
[2016-06-15 16:46:15 +0000] [1] [INFO] Starting gunicorn 19.5.0
[2016-06-15 16:46:15 +0000] [1] [DEBUG] Arbiter booted
[2016-06-15 16:46:15 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2016-06-15 16:46:15 +0000] [1] [INFO] Using worker: sync
[2016-06-15 16:46:15 +0000] [8] [INFO] Booting worker with pid: 8
[2016-06-15 16:46:15 +0000] [9] [INFO] Booting worker with pid: 9
[2016-06-15 16:46:15 +0000] [10] [INFO] Booting worker with pid: 10
[2016-06-15 16:46:15 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2016-06-15 16:46:52 +0000] [9] [INFO] Worker exiting (pid: 9)
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:10)
[2016-06-15 16:46:52 +0000] [10] [INFO] Worker exiting (pid: 10)
[2016-06-15 16:46:53 +0000] [20] [INFO] Booting worker with pid: 20
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 2 workers
[2016-06-15 16:46:53 +0000] [21] [INFO] Booting worker with pid: 21
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:47:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:8)
(...)

`

谢谢。

我也在看这个。 我怀疑是弹性负载均衡器。 我们曾经在以前的公司中使用paste ，这会导致 ELB 出现问题。 我相信它以某种方式重新使用连接，这导致paste故障。

我现在在一份新工作中使用 gunicorn，一切都很好，直到我们开始将服务器放在 ELB 后面，webapp 现在通常非常无响应并且似乎挂起。

尝试改用gevent工人，这为我解决了这个问题。

那么这是 ELB 保持连接活动并占用同步工作者的问题吗？ 这会让我觉得很奇怪，因为我们故意发出信号应该用同步工作者关闭连接： https :

不过，我们可以故意关闭连接。 如果有人想测试将client.close()调用移动为无条件，这可能是一个有趣的测试： https :

您还可以确保 ELB 上的空闲超时低于工作超时，作为一个快速的健全检查，这甚至是问题的原因： http :

@tilgovi elb 是我目前最好的猜测，因为 a) 只有当 gunicorn 位于 ELB 后面时才会发生这种情况，并且 b) 问题是通过使用gevent工人解决的。 但话又说回来，谁知道..

它只发生在 ELB 之后，并且如果在 ELB 上设置了 HTTP 或 HTTPS 协议。
如果您将协议更改为 TCP 或 SSL，问题就会消失。
有谁知道如何修复它仍然使用同步工作者？ 直到现在，我使用了我描述的修复程序（TCP 而不是 HTTP），当我要监视访问日志并查看 X-Forwarded-For 标头时，它仅在 ELB 上为 HTTP/HTTPS 启用:)

奇怪，只是为了确保我们在同一页面上，这意味着在 ELB 中使用 HTTP/HTTPS 选项时有某种优化吗？ 这种优化会导致同步工作者出现问题吗？

@ecs我认为在 HTTP/HTTPS 负载平衡器重用相同的 TCP 连接的情况下，ELB 长时间保持活动状态 - 某种程度。 但这并没有解释为什么 gevent worker 工作正常......（虽然我还没有测试 gevent，只是从这些评论中阅读）

顺便说一句，肯定有很多因素（gunicorn 版本、worker 类、docker 内部与否、ELB 协议）会产生影响，所以如果有人能测试并确认 ELB 上的 TCP 协议与 HTTP 不同，那就太好了。 我正在 Ubuntu 14.04 和 gunicorn 版本 19.3.0 上托管的 docker 上进行测试

我也有同样的问题：
[2016-10-03 12:13:17 +0000] [6] [关键] 工人超时 (pid:16)
[2016-10-03 12:13:17 +0000] [16] [INFO] 工人退出 (pid: 16)
[2016-10-03 12:13:17 +0000] [6] [关键] 工人超时 (pid:20)
[2016-10-03 12:13:17 +0000] [20] [INFO] 工人退出 (pid: 20)
[2016-10-03 12:13:17 +0000] [33] [INFO] 使用 pid 启动 worker：33

我的设置。

我正在使用 kube-aws 在 AWS 上使用 core-os 设置 kubernetes 集群： https :

我有一个使用 gunicorn 和同步工作器的 python 应用程序。 他们的服务使用带有我的站点证书的 HTTPS 负载平衡器。 在默认的 30 秒超时时间之后，所有工作人员都被视为超时。 他们最终都重新启动。 Kubernetes 最终会在容器退出时重新启动容器。这些重新启动会持续发生。 上面有人提到 gevent 解决了这个问题，我可以尝试一下，但我真的很想了解为什么会发生这种情况。

我们目前也看到了这个问题，我会在有机会时尝试发布更多详细信息。 它与同步工作者有关，因为移动到 gevent 确实解决了这个问题。 这是在带有 ECS 和 ELB 的 AWS 上。

我们的一个应用程序也有同样的奇怪问题。 将侦听器从 HTTP 更改为 tcp 确实解决了问题。

任何人都可以为我提供重现问题的分步方法？ （配置步骤等）或者至少给我指出一种设置该环境的简单方法:) 我这周会看看它。

依靠 HTTP 来实现这种平衡器通常需要处理 keep-alive（tcp 除外），因此在同步工作器更新以支持其支持之前，使用同步工作器的任何事情都可能是一个问题。

无论如何让我知道。

只需设置一个基本的 Flask 应用程序，并在 AWS 上的 docker 内部使用带有同步工作器的 gunicorn 运行它，使用 HTTP 负载平衡和上面的配置：

在 Docker 映像中使用 gunicorn 19.4.5，该映像在 AWS 上的 Ubuntu 14.04 LTS 上运行，当使用 >1 同步工作器和默认的 30 秒超时时间运行时，我看到持续的工作器超时。

您不必向应用程序发出任何请求，只需监视日志，您就会看到工作人员超时。

• 我可以确认这种行为以及重现它的基本方法。
  
  
  
  • 该行为不仅限于 Docker，而是适用于同步工作者/保持活动设置，因此您可以考虑更改标题...
  
  
• 我已经修改了 keepalive 设置以遵循此处描述的内容： https :
• 此外，我还更改了 gthread 工作程序类，发现到目前为止结果是非常可以接受的。

我目前正在使用超时时间为 65 秒的 gevent 工作线程（AWS ELB 超时为 60 秒，AFAIK）。 我有时仍然会遇到 504 错误，即使只有一个客户端发出请求，一次有 1 个请求在发送，但我还无法确定原因。

@obi1kenobi您是否尝试将 keepalive 增加到超出 ELB 超时选项？

@lenucksi ，keepalive 已经比 ELB 超时高了 5 秒——希望服务器的时钟不会驱动那么多:)

我在 ELB 后面的 EC2 实例上的 Docker 容器内运行 gunicorn 19.6 时也遇到了这个问题（使用默认 HTTP 协议反向代理到 EC2 实例）。

如前所述，将工作人员类设置为 gevent 为我解决了这个问题（以前我一直使用默认的sync工作人员类）。

我将尝试记录一个重现问题的最小示例。

为了证实其他人所说的话，ELB 似乎正在打开与 EC2 实例的连接并保持打开状态，从而阻止 gunicorn 处理其他请求。

当这个保持打开的连接由于 Gunicorn 超时 ELB 的请求而终止时，所有在它后面排队的未决请求也会失败（包括 ELB 的健康检查，导致实例从 ELB 中删除，使其更难调试； ) )。

此症状表明这是上一期与 Docker 无关的观察结果的重复： https :

@jelis你知道这是否与某些 kubernetes 配置有关吗？ 你的问题解决了吗？

我也在使用 SSL 终止的 ELB。 我在日志中看到了这一点：

[017-03-01 07:36:32 +0000] [1249] [DEBUG] GET /healthcheck
[01/Mar/2017:07:36:32 +0000] "GET /healthcheck HTTP/1.1" 200 22 "-" "ELB-HealthChecker/1.0"
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1203)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1225)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1234)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1243)
[017-03-01 07:36:37 +0000] [1203] [INFO] Worker exiting (pid: 1203)
[017-03-01 07:36:37 +0000] [1225] [INFO] Worker exiting (pid: 1225)
[017-03-01 07:36:37 +0000] [1243] [INFO] Worker exiting (pid: 1243)
[017-03-01 07:36:37 +0000] [1234] [INFO] Worker exiting (pid: 1234)
[017-03-01 07:36:37 +0000] [1256] [INFO] Booting worker with pid: 1256
[017-03-01 07:36:37 +0000] [12] [DEBUG] 14 workers
[017-03-01 07:36:37 +0000] [1257] [INFO] Booting worker with pid: 1257
[017-03-01 07:36:37 +0000] [1262] [INFO] Booting worker with pid: 1262
[017-03-01 07:36:37 +0000] [1265] [INFO] Booting worker with pid: 1265
[017-03-01 07:36:37 +0000] [12] [DEBUG] 16 workers
[017-03-01 07:36:40 +0000] [1262] [DEBUG] GET /healthcheck

更新 - 我刚刚从 gunicorn 切换到 gevent (http://flask.pocoo.org/docs/0.12/deploying/wsgi-standalone/#gevent)，问题解决了。 这是参考我上面的评论https://github.com/benoitc/gunicorn/issues/1194#issuecomment -283269046

这几天我一直在讨论这个问题。 这里每个人的笔记都很棒，并为我们提供了许多寻求修复/解决方法/缓解措施的途径。 （我的工作日志在我们在这里跟踪的错误中）

我只是尝试使用gevent来增加工人数量，但这根本没有帮助我们 - 事实上它令人惊讶地让它看起来更糟 - 所有五个 gevent 工人同时死亡，这是来自我在上面读到的：

[2017-03-30 23:38:37 +0000] [5] [INFO] Starting gunicorn 19.7.1
[2017-03-30 23:38:37 +0000] [5] [INFO] Listening at: http://0.0.0.0:8000 (5)
[2017-03-30 23:38:37 +0000] [5] [INFO] Using worker: eventlet
[2017-03-30 23:38:38 +0000] [8] [INFO] Booting worker with pid: 8
[2017-03-30 23:38:40 +0000] [9] [INFO] Booting worker with pid: 9
[2017-03-30 23:38:41 +0000] [11] [INFO] Booting worker with pid: 11
[2017-03-30 23:38:42 +0000] [12] [INFO] Booting worker with pid: 12
[2017-03-30 23:38:42 +0000] [10] [INFO] Booting worker with pid: 10
[2017-03-30 23:40:08 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:8)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:10)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-03-30 23:40:13 +0000] [8] [INFO] Worker exiting (pid: 8)
[2017-03-30 23:40:13 +0000] [10] [INFO] Worker exiting (pid: 10)
[2017-03-30 23:40:16 +0000] [16] [INFO] Booting worker with pid: 16
[2017-03-30 23:40:16 +0000] [17] [INFO] Booting worker with pid: 17
[2017-03-30 23:40:18 +0000] [18] [INFO] Booting worker with pid: 18
[2017-03-30 23:40:20 +0000] [19] [INFO] Booting worker with pid: 19
[2017-03-30 23:40:23 +0000] [20] [INFO] Booting worker with pid: 20

这可能是我的一些失误，并且与我的项目同行之一的行为不同（在几乎相同的 AWS/CloudFormation/ALB/ECS 部署中具有相似但不相同的代码库）。 但是我想我会报告它，以防它激发对 ALB、ECS、Docker 和 gunicorn 之间交互的任何新见解。

我有一个类似的设置（convox 运行 ELB->ECS Docker Container->Gunicorn->Django），我可以确认以下配置更改似乎有所帮助：

keepalive = 75 # needs to be longer than the ELB idle timeout
timeout = 90
worker_class = 'gevent'

我将 ELB 空闲超时设置为 60 秒。

在更改这些设置之前，我使用了 keepalive、超时和同步工作器的默认值。

有趣的是，这个问题在 UTC 4 月 10 日凌晨 4 点开始出现。自上周四以来，该应用程序一直运行良好，没有任何变化。

只是堆积，没有 docker，但裸 aws 实例在 ELB 后面有同样的问题。 在 osx 上运行 NP，但 ubuntu16 出现了同样的问题。 gevent工人班似乎[为我] 解决了这个问题。

这个线程中的任何人都可以检查这个吗？
https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx

@erikcw似乎找到了这个解决方案。 我想关闭这个问题。 如果有人可以在提高 Gunicorn 工作超时和保活超时后重现这一点，请说出来。

或者，降低 ELB 的空闲超时。

野外的客户端（或恶意客户端）不能像 ELB 一样导致同样的问题吗？

@six8是的。 ELB 也不会保护您免受此影响。 文档对此进行了讨论： http :

有些人不关心这种威胁，只想在 ELB 的边缘或后面部署 Gunicorn。 这里讨论的问题是由 ELB 本身引起的工作超时。 我想提供推荐的配置，使 gunicorn 在 ELB 后面使用同步工作器工作，而无需额外的反向代理。

我也尝试了@erikcw的解决方案，方法是将 gunicorn 调用更改为：

CMD [ "gunicorn", "-k", "gevent", "--timeout", "10", "--keep-alive", "75", "--paste", "/etc/jzoo/app.ini" ]

不幸的是，这无济于事：

[2017-07-04 08:36:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:24)
[2017-07-04 08:38:11 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:28)
[2017-07-04 08:39:39 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:29)
[2017-07-04 08:44:14 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-07-04 08:44:55 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:31)

我有一个在带有 Gunicorn 同步工作器的 ALB 后面的 ECS 上运行的应用程序。 我还没有看到任何问题。

任何人都可以提供可重现的部署吗？

堆积如山。 在 AWS 上使用 Kubernetes 和 ELB 看到这个问题。 目前有8名工人在运行。 根据https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ ，我们将增加keepalive ，并根据此线程尝试改为使用gevent工人。 但是现在，失败的是 api 调用的一些性能测试，这些测试不应该自己阻塞/导致超时。 想知道sync工人这里发生了什么。 即使我们按照本主题中的一些好的指导方针进行了这项工作，我们也希望在部署到生产之前对发生的事情更有信心。

将 --worker-class 设置为--worker-class gevent对我有用。 感谢您的评论和帮助！

@wichert这很奇怪。 对于 gevent worker，worker 应该在与任何连接分开的 greenlet 上通知仲裁者他们的活跃度。 您的保持活动设置根本不应该影响这一点。 您的应用程序出现问题，例如 gevent 无法按设计工作，或者有关设置的某些问题可能在这些其他场景中很常见。

请在此线程上的每个人提供一个重现此问题的应用程序。 我一直无法重现它。 没有重现的步骤，我很想关闭。 这些评论中包含多种建议，可能还有非常不同的问题。 很难知道如何处理这个问题。

@tilgovi我在没有将工作类指定给 gevent 时遇到了这个问题（例如，使用默认的同步工作）。 我的设置是使用 pypy3（PyPy 5.8.0-beta0）、falcon 1.2 等的 virtualenv（了解 pypy3 不正式支持 Falcon）。 我使用了来自https://github.com/7ideas/cookiecutter-falcon的 cookiecutter 并升级到所有最新的软件包，并尝试在浏览器中加载 sample_resource 并使用 httpie 多次点击它会间歇性地看到工作崩溃错误（例如，请求会被延迟，然后我会看到错误；如果我没有取消请求，它最终会响应）。 这只发生在默认的同步工作类中。 当我指定它使用 gevent 时，一切正常。

谢谢@jhillhouse92 ，我会试试的。

我继续看到超时问题，@tilgovi。 明天我将对此进行更多故障排除，并将发布包含更准确信息的更新。 请保持这个问题开放； 你是对的，可能会出现各种各样的问题，但总的主题是，gunicorn 工作人员（可能只是同步工作人员类，tbd）在将 gunicorn 与使用 AWS/ELB 部署的应用程序一起使用时遇到超时问题。 即使我们没有隔离确切的问题，这里也有问题。 值得进一步挖掘。 我明天更新。

值得注意的是，我不是在 Docker/AWS/ELB 中使用我提到的上述堆栈在本地遇到了这个问题。

所以我正在使用 gevent，尝试捕获我的访问日志，并尝试使用 AWS/ELB 部署我的应用程序。

dockerfile 命令：

FROM cortex/base

CMD ["gunicorn", "-w", "8", "-b", "0.0.0.0:5000", "--capture-output", "--enable-stdio-inheritance", "--access-logfile", "-", "--worker-class", "gevent", "-t", "60", "--log-level", "debug", "app:app"]

无论我将限制设置为什么，我都会收到与错误代码 14 相关的疯狂 OOM 错误。 有没有其他人在这个问题的背景下看到过这一点？ 以前，我能够看到工作人员超时。 使用我当前的配置，我无法重现超时/达到那么远。

[2017-07-19 18:27:39 +0000] [34] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/ggevent.py", line 190, in init_process
    super(GeventWorker, self).init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.load_wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/usr/local/lib/python3.5/site-packages/gunicorn/util.py", line 376, in import_app
    __import__(module)
  File "/code/app/__init__.py", line 2, in <module>
    from flask_alchy import Alchy
  File "/usr/local/lib/python3.5/site-packages/flask_alchy.py", line 8, in <module>
    from flask_sqlalchemy import SQLAlchemy
  File "/usr/local/lib/python3.5/site-packages/flask_sqlalchemy/__init__.py", line 18, in <module>
    import sqlalchemy
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/__init__.py", line 9, in <module>
    from .sql import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/__init__.py", line 8, in <module>
    from .expression import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/expression.py", line 34, in <module>
    from .functions import func, modifier, FunctionElement, Function
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/functions.py", line 11, in <module>
    from . import sqltypes, schema
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 658, in exec_module
  File "<frozen importlib._bootstrap_external>", line 763, in get_code
  File "<frozen importlib._bootstrap_external>", line 816, in get_data
OSError: [Errno 14] Bad address

重申一下，我在没有 docker 的情况下在本地看不到这一点。 我在 Docker 本地看不到这一点。 这个和超时问题只会在 Docker/AWS/ELB 堆栈中出现（对我来说）。

@tilgovi我最初做错的一件事（从我上面发布的片段中可以看出）是我错误地将超时设置为 10 秒。 将其更改为 75 秒后，工作超时的数量显着减少到每天几次。 为了完整起见，这是我用来启动我们的应用程序的确切命令：

gunicorn -k gevent --timeout 90 --keep-alive 75 --paste /etc/jzoo/app.ini "$@"

.ini 文件如下所示：

[DEFAULT]
sqlalchemy.url = postgresql://XXXX

[app:main]
use = egg:jzoo.api.admin

[server:main]
use = egg:gunicorn#main
bind = 0.0.0.0:5000
workers = 4
preload_app = true
loglevel = warning

# Logging configuration
[loggers]
keys = root,sqlalchemy,alembic,jzoo

# .. more logging configuration

流量似乎不是一个因素 - 我看到这种情况发生在我们的 QA 环境中，只有很少的流量。

看看这种情况发生的频率，我想知道这是否与应用程序重启有关？

我有一个有点类似的问题。 经过一番调查，我认为这可能是网络连接错误，而不是gunicorn的。

这是我的设置：

• Postgresql 服务器在 EC2 上的 Docker 上运行。 docker 镜像是官方的 postgres 9.6。
• 应用服务器在 EC2 之外的 VM 中的 Docker 上运行。 docker 镜像是官方的python 3.6。
• AWS 安全组中仅打开端口 5432 / tcp。

有趣的是，从应用服务器到 postgres 服务器的大多数请求都可以，除了一个。 该查询似乎永远运行，这使 gunicorn 工人超时。

如果我在本地使用该应用程序，问题就消失了。

如果我不 dockerize 应用服务器，问题也会消失。

我的临时修复是通过 AWS 安全组设置打开应用服务器和 postgres 服务器之间的所有连接。 现在一切正常。

我猜测 Python 容器和 AWS 之间存在连接问题。 我会在彻底检查 AWS 日志流后更新。

谢谢！！ 将 ELB 和实例协议从 HTTP 更改为 TCP 效果很好👍

这个问题似乎不是 AWS 特有的，而是与 Gunicorn 结合使用时 Docker 本身的问题。 我在gevent中也看到了这一点，至少在我们的生产环境中是这样。

@tilgovi这是一个简单的应用程序来重现这个错误（

应用程序.py：

import falcon


class HelloResource:
    def on_get(self, req, resp):
        resp.media = {'info': 'hello world'}


app = falcon.API()
app.add_route('/', HelloResource())

Dockerfile：

FROM python:3.6
WORKDIR /code
RUN pip install gunicorn falcon
COPY app.py .
CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

运行： docker build -t gunicorn-and-docker . && docker run -p 8000:8000 -it --rm gunicorn-and-docker

日志看起来像这样（至少对于我在 macOS Sierra 上使用 Docker 17.06.2-ce-mac27 (19124)）：

[2017-09-23 22:31:00 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-09-23 22:31:00 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2017-09-23 22:31:00 +0000] [1] [INFO] Using worker: sync
[2017-09-23 22:31:00 +0000] [9] [INFO] Booting worker with pid: 9
[2017-09-23 23:22:45 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-09-23 23:22:45 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-09-23 23:22:45 +0000] [11] [INFO] Booting worker with pid: 11
[2017-09-23 23:39:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-09-23 23:39:46 +0000] [11] [INFO] Worker exiting (pid: 11)
[2017-09-23 23:39:46 +0000] [13] [INFO] Booting worker with pid: 13
[2017-09-23 23:41:10 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:13)
[2017-09-23 23:41:10 +0000] [13] [INFO] Worker exiting (pid: 13)
[2017-09-23 23:41:10 +0000] [15] [INFO] Booting worker with pid: 15
[2017-09-23 23:42:27 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:15)
[2017-09-23 23:42:27 +0000] [15] [INFO] Worker exiting (pid: 15)
[2017-09-23 23:42:27 +0000] [17] [INFO] Booting worker with pid: 17
[2017-09-23 23:43:44 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:17)
[2017-09-23 23:43:44 +0000] [17] [INFO] Worker exiting (pid: 17)
[2017-09-23 23:43:44 +0000] [19] [INFO] Booting worker with pid: 19
[2017-09-24 18:37:12 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:19)
[2017-09-24 18:37:12 +0000] [19] [INFO] Worker exiting (pid: 19)
[2017-09-24 18:37:12 +0000] [21] [INFO] Booting worker with pid: 21
[2017-09-24 19:49:20 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:21)
[2017-09-24 19:49:20 +0000] [21] [INFO] Worker exiting (pid: 21)
[2017-09-24 19:49:20 +0000] [23] [INFO] Booting worker with pid: 23
[2017-09-24 19:50:37 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:23)
[2017-09-24 19:50:37 +0000] [23] [INFO] Worker exiting (pid: 23)
[2017-09-24 19:50:37 +0000] [25] [INFO] Booting worker with pid: 25
[2017-09-24 20:25:48 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-09-24 20:25:48 +0000] [25] [INFO] Worker exiting (pid: 25)
[2017-09-24 20:25:48 +0000] [27] [INFO] Booting worker with pid: 27

你好，

我最近遇到了同样的问题。
在我的情况下（ECS + gunicorn 19.7.1 + Django 1.11.5），我（显然）设法通过简单地增加任务定义中容器专用的内存量（从 128 到 256mb）来解决它。
到目前为止没有更多错误。 如果再次发生，我会在这里报告。

在这里添加一些合唱，但我只能通过切换到 gevent 来解决这个问题。

我尝试将超时时间增加到 90 并将 keepalive 增加到 75，但没有运气。

另外，有趣的是，我在这个场景中的 ELB 只做 TCP 级别的转发，而不是 HTTP。

好的，我找到了一些解释这一点的参考资料。 [1]

它可以通过 Gunicorn 方面的小改动来解决。 如果在同步工作线程中，在接受一个新连接后，我们在短时间内调用select() ，那么我们就可以处理这些连接。 它可能会变得有点复杂，尤其是使用多个侦听套接字时。 最简单的事情是对第一个字节设置超时。 我也不确定这将如何与 SSL 交互。

[1] https://cloudavail.com/2013/12/21/aws-elb-pre-open-connection-expose-part-1/

如果您遇到这种情况并且不想使用 gevent/eventlet/asyncio，我建议您切换到线程工作者（提供--threads设置）。

@tilgovi这个问题似乎也存在于 gevent worker 中，如果你看看我上面的例子。

@jmagnusson您的示例（来自此评论：https://github.com/benoitc/gunicorn/issues/1194#issuecomment-331740187）似乎正在使用同步工作者。

[2017-09-23 22:31:00 +0000] [1] [INFO] 使用工人：同步

@tilgovi是的，但我在生产中也遇到过gevent工人的情况。 我会尽量找一些时间用 gevent 进行复制。

这可能只是我（傻），但在 EC2 安全组 -> 入站规则中，我有一个自定义 TCP 规则，用于端口 5000（此处为 gunicorn），仅允许一个 IP（我的 IP：XX.XX.XX.XX /32)，将其更改为所有 IP 会有所帮助。

我也遇到了麻烦。

[2018-01-02 16:38:03 +0800] [24355] [INFO] Starting gunicorn 19.7.1
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] Arbiter booted
[2018-01-02 16:38:03 +0800] [24355] [INFO] Listening at: http://0.0.0.0:8080 (24355)
[2018-01-02 16:38:03 +0800] [24355] [INFO] Using worker: gevent
[2018-01-02 16:38:03 +0800] [24358] [INFO] Booting worker with pid: 24358
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] 1 workers
[2018-01-02 16:38:03 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:04 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:05 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:06 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:07 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:08 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:09 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:10 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] Closing connection. 
[2018-01-02 16:38:41 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24358)
[2018-01-02 16:38:41 +0800] [24358] [INFO] Worker exiting (pid: 24358)
[2018-01-02 16:38:41 +0800] [24381] [INFO] Booting worker with pid: 24381
[2018-01-02 16:38:41 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:42 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:43 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:44 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:45 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:46 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:47 +0800] [24381] [INFO] worker pid 24381 notify
......
[2018-01-02 16:48:20 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:48:51 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24381)
[2018-01-02 16:48:51 +0800] [24381] [INFO] Worker exiting (pid: 24381)
[2018-01-02 16:48:51 +0800] [24703] [INFO] Booting worker with pid: 24703
[2018-01-02 16:48:51 +0800] [24703] [INFO] worker pid 24703 notify
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] Closing connection. 

我添加了调试日志worker pid {WORKER_PID} notify 。

根据调试日志，

1. 只有当工作进程收到一个请求时，通知才会继续。 所以，不管有没有请求，master 都会在 30s 后杀死 worker 进程。
2. 第一个请求关闭后，我立即发送了第二个请求，但是第二个请求被阻止并且没有响应。 当 30 秒超时到达时，工作进程被杀死，新的工作进程将响应第二个请求。 然后服务器又挂了。
3. 当工作进程挂起时，它不会收到来自主进程的信号，例如SIGTERM 。 当优雅超时到达时，master 会强制杀死它SIGKILL 。

Python: 3.6.3
Gevent: 1.2.2
Gunicorn: 19.7.1
RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

注意：当我使用eventlet作为 worker 时，没问题。

我将关闭这个问题，因为我认为它有点过时了。 据我所知，观察到的行为是由于 AWS Classic Load Balancer 进行了预开放优化。 根据负载平衡如何工作的本博客文章所述，可以请求 AWS 禁用预开放优化或增加 Gunicorn 的工作线程超时。

@tilgovi FWIW 我在 ALB 上看到了这个。 我从未使用过经典的负载均衡器。

@tilgovi我也在仅 ALB 的环境中反复观察到这一点，从未使用过经典。 即使工作人员超时调整，我们仍然看到这一点。

@tilgovi我遇到了这个。 我从未使用过 AWS。

然后，必须有人帮助重现这一点，并尝试对其进行调试。 我无法用 ALB 重现它，也看不到如何在 AWS 之外重现它。

@xgfone你可能想打开你自己的问题，这个问题的标题是“docker + AWS”

有没有人在使用 AWS 负载均衡器但没有使用 Docker 时遇到过这种情况？ 我有点困惑，我不得不承认:)

我的印象是这个问题确实与 Docker 更相关——至少我在本地机器上的 Docker 内运行多个 gunicorn 同步工作器时遇到了完全相同的问题。

这个配置在没有 Docker 的 Ubuntu 和 RHEL 机器上运行良好，裸机和在 Digital Ocean 中虚拟化：

workers = 2
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

在 Docker（也是 RHEL，其他一切都一样）内部，worker 总是遇到超时并永久重启。 从这个线程中获取建议，我已经切换到这个，它工作得很好：

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

如果您认为这与该线程无关，我很乐意将其从此处删除并将其放在其他地方；-)

最好的，鲍里斯

@tilgovi

此错误发生在 arbiter.py, murder_workers 。 murder_workers函数在SIG_QUEUE为空时调用（例如在等待信号时）。

然后它会检查是否每秒达到超时。 剩余生存时间始终为 1 秒或 0 秒，因为 gevent 工作程序处于受控无限循环中，而self.alive调用self.notify更新文件。 文件的更新是 gunicorn 如何检查上次活动时间发生的时间。

因此， murder_workers函数中的存活时间检查失败（例如说它空闲太久）的唯一方法是 gevent 活动属性是否已更改。 以下方法可以控制这一点：

handle_quit
handle_request （如果收到最大请求数，默认情况下这是请求数的 2^64 位，如果是 32 位操作系统，则为 2^32）
changed （如果文件被更改，则从重新加载器调用）
handle_exit
handle_abort

这些方法是从信号中调用的

handle_quit - SIGQUIT, SIGINT
handle_exit - SIGTERM
handle_abort - SIGABRT

因此，我看到有两个可能的问题：

1. 通知方法无法在其循环期间更新文件
2. 信号被错误地发送

我认为更可能的原因是第二个。 信号的主要来源在仲裁文件中，并由以下异常触发：

• StopIteration
• KeyboardInterrupt
• HaltServer
• Exception （未处理的异常）

我认为 StopIteration 异常很可能是在req = six.next(parser)的 async.py 文件中触发的罪魁祸首。 看起来这个 next 方法只是调用 parser.next()。

Parser.next()在以下两种情况下引发StopIteration异常：

1. If the message indicates it should close:
    1. http Connection close (and keep-alive false)
    2. WSGI - request method not HEAD, response_length is none, and status code is > 200 (but not 204, or 304)
2. If self.mesg (Request message) is falsey

我不确定究竟是什么原因无意中导致了这种情况，但在 62 条评论中，在多个应用程序和环境中都看到了这个问题，我认为这值得进一步调查并建议重新打开它，或者如果我们不喜欢标题, 造成工人严重超时的新全球问题。

我将重新打开它并尝试测试这些组合：

• 本地 Docker
• 带有 Classic Load Balancer 的 Docker AWS
• 带有应用程序负载均衡器的 Docker AWS

如果有人想创建一个可以重现此内容的存储库，那会很有帮助，但我可能会在本周末完成。

我遇到了这个问题，而且我没有使用 AWS。
我的设置是 NGINX -> Docker 容器（Gunicorn with gevent workers + Django）。 我正在使用 Gunicorn 的默认超时。

有小费吗？

谢谢。

嗨@davidmir ，
我遇到了同样的问题，更改工人类型没有帮助。 切换到具有多个线程的单个同步工作器对我来说很有效：

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

最好的，鲍里斯

虽然上面提到了一些，但为了从我自己对此问题的调试中澄清，其中一些是内存不足错误； 特别是如果它通过将工人计数减少到 1 来解决。

如果你的配置中有这样的东西，这在 Docker 上尤其成问题：

workers = multiprocessing.cpu_count() * 2 + 1

但是限制了容器可用的内存； 同步 worker 将启动多个潜在的重量级 python 解释器。 请注意，CPU 数量基于机器的总体 CPU 数量，而不是您配置 docker 容器使用的数量； 如果你正在运行一个有限的容器，你应该基于它来计算工作人员的数量。

虽然它因应用程序而异，但我的经验法则是在精益配置中每个工人 256 megs，安全配置为 512 megs。

使用 Classic ELB HTTPS => HTTP Gunicorn Sync Workers 面临同样的问题

正如其他人提到的，最简单的解决方法是使用-k gevent参数而不是默认同步工作器。

我们看到一个全新的 Docker 容器（托管在 ALB 后面的 ECS 中）再次出现同样的问题，并发现了一个完全不同的（但事后看来，应该是显而易见的）解决方案：在 CloudFormation 中为容器分配更多内存模板。

去年我们遇到了这个问题，从来没有找到真正的根本原因，但今晚我在一个新容器上发现了它，并且碰巧注意到这个容器正在吃掉我们分配的所有内存。 一旦我将分配加倍，容器就停止抛出此错误（甚至在我分配的数量超过最终消耗的数量之前）：
https://github.com/hackoregon/civic-devops/issues/157

在这里面临类似的问题。 代码很简单

while true:
      sleep(10)

可能导致工人死亡（没有此代码，我们的部署是正常的）
这很令人费解，b/c sleep应该已经发送心跳了。

也已经改成gevent了，没用。 不知道有人有什么想法吗？

示例输出：
[2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:521) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:522) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:523) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:524) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:525) [2018-06-16 16:00:16 +0000] [524] [INFO] Worker exiting (pid: 524) [2018-06-16 16:00:16 +0000] [521] [INFO] Worker exiting (pid: 521) [2018-06-16 16:00:16 +0000] [523] [INFO] Worker exiting (pid: 523) [2018-06-16 16:00:16 +0000] [522] [INFO] Worker exiting (pid: 522) [2018-06-16 16:00:16 +0000] [525] [INFO] Worker exiting (pid: 525) [2018-06-16 16:00:17 +0000] [531] [INFO] Booting worker with pid: 531 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [136] [DEBUG] 1 workers [2018-06-16 16:00:17 +0000] [532] [INFO] Booting worker with pid: 532 [2018-06-16 16:00:17 +0000] [533] [INFO] Booting worker with pid: 533 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [534] [INFO] Booting worker with pid: 534 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [535] [INFO] Booting worker with pid: 535 [2018-06-16 16:00:17 +0000] [136] [DEBUG] 5 workers

很抱歉在这里弄脏了水，但只是想分享我的经验，我的堆栈是HTTP ELB > Nginx > gunicorn/gevent on EC2 ，进程使用 circusd 运行

我发现的问题是，在使用elastic-apm检测我的 django 应用程序后，我的 HTTP 运行状况检查几乎立即开始失败，几秒钟后 gunicorn 将变得无响应。

我针对我的健康检查尝试了一些本地wrk基准测试，1-5 名工人的同步速度约为 300rps，但 gevent 会达到 1rps。 关闭 apm 使 gevent 达到大约 50rps，并且同步增加可以忽略不计。

没有注意到 valgrind 上有任何奇怪的内存使用情况，gunicorn 通常约为 4MB，每个 worker 约为 40MB

无论如何，更新gunicorn 19.6.0 > 19.9.0和gevent 1.2.2 > 1.3.6再次给了我一个稳定的 ELB 健康检查和 ~300rps 本地。 我故意没有更新 gunicorn/gevent 直到我有一些 APM 登录到位，似乎这样做引起了一些意外。 可以理解，更新 gevent 带来了最大的提升，但随后更新 gunicorn 似乎又增加了 10% 左右。

还没有详细查看变更日志，也许维护人员可以阐明最可能的原因？

无论如何，更新 gunicorn 19.6.0 > 19.9.0 和 gevent 1.2.2 > 1.3.6 再次给了我一个稳定的 ELB 健康检查和 ~300rps 本地......更新 gevent 给了最大的推动

哇，这很酷！

结题。 好久没有活动了。

FWIW，我仍然有这个问题@benoitc :-\

Django 2.1.5
枪炮 19.8.1
事件 1.2.2
带有 5 个节点的 AKS 1.15.7（标准 B2 - 2 个 vcores 和 2GB 内存）
3 个 pods/docker 容器，每个容器都有：

    spec:
      containers:
        - name: web-container
          command: ["newrelic-admin"]
          args: [
              "run-program",
              "gunicorn",
              "--limit-request-field_size=16380", # limit also specified in nginx
              "--workers=3", # (2 x vcpu) + 1. vcpu < limit defined in resources
              "-k=gevent",
              "-b=0.0.0.0:8000",
              "ourapp.wsgi",
              "--timeout 60",
              "--log-level=debug",
            ]
          resources:
            requests:
              memory: "200Mi"
              cpu: "250m"
            limits:
              memory: "3000Mi"
              cpu: "2000m"

EKS、Nginx 和 NLB 也有同样的问题。

@salmicrosoft @sinkr好的，但请打开一个新问题并提供您拥有的任何日志，以帮助我们弄清楚发生了什么。 还有你的应用程序是什么？ 你有什么长期的要求吗？

我在 ECS Fargate 上遇到了同样的问题，但它与 Docker/gunicorn.conf.py 中不正确的 keepalive/timeout 设置有关，它是
保活（未设置）
超时=2

在修复它之前，它在本地运行的容器上运行良好，但在 ECS Fargate 上失败了，现在它可以在两种环境中正常运行。