오류가 예상되지는 않지만 오류가 발생하는 이유를 보여주는 예제는 없습니다. 귀하의 환경에 대해 자세히 알려주십시오.

• Gunicorn에 연결하는 데 사용되는 클라이언트는 무엇입니까?
• Gunicorn에 연결하는 데 사용되는 역방향 프록시(있는 경우)는 무엇입니까?

귀하의 환경에 대해 자세히 알려주십시오.

• Gunicorn에 연결하는 데 사용되는 클라이언트는 무엇입니까?
  => Chromium에서 요청을 보냅니다. http://localhost :5000/
• Gunicorn에 연결하는 데 사용되는 역방향 프록시(있는 경우)는 무엇입니까?
  => 프록시 없음, Gunicorn + Flask만 있음

방금 완전히 새로운 설정에서 문제를 재현했습니다. 단계는 다음과 같습니다.

mkdir gunicorn
cd gunicorn/
pipenv --python 3.6
pipenv install flask
pipenv install gunicorn
vim hello.py
pipenv shell
gunicorn -b 0.0.0.0:5000 --log-level=debug hello

hello.py 는 내가 초기 보고서에 게시한 것과 정확히 동일한 Flask 애플리케이션입니다.
아래는 전체 로그입니다.

~$ gunicorn -b 0.0.0.0:5000 --log-level=debug hello
[2018-06-06 09:16:21 +0200] [19829] [DEBUG] Current configuration:
  config: None
  bind: ['0.0.0.0:5000']
  backlog: 2048
  workers: 1
  worker_class: sync
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /home/dima/work/gunicorn
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1000
  group: 985
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: None
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: -
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  statsd_prefix: 
  proc_name: None
  default_proc_name: hello
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f9757112d08>
  on_reload: <function OnReload.on_reload at 0x7f9757112e18>
  when_ready: <function WhenReady.when_ready at 0x7f9757112f28>
  pre_fork: <function Prefork.pre_fork at 0x7f9756c230d0>
  post_fork: <function Postfork.post_fork at 0x7f9756c231e0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f9756c232f0>
  worker_int: <function WorkerInt.worker_int at 0x7f9756c23400>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f9756c23510>
  pre_exec: <function PreExec.pre_exec at 0x7f9756c23620>
  pre_request: <function PreRequest.pre_request at 0x7f9756c23730>
  post_request: <function PostRequest.post_request at 0x7f9756c237b8>
  child_exit: <function ChildExit.child_exit at 0x7f9756c238c8>
  worker_exit: <function WorkerExit.worker_exit at 0x7f9756c239d8>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f9756c23ae8>
  on_exit: <function OnExit.on_exit at 0x7f9756c23bf8>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: TLSv1
  raw_paste_global_conf: []
[2018-06-06 09:16:21 +0200] [19829] [INFO] Starting gunicorn 19.8.1
[2018-06-06 09:16:21 +0200] [19829] [DEBUG] Arbiter booted
[2018-06-06 09:16:21 +0200] [19829] [INFO] Listening at: http://0.0.0.0:5000 (19829)
[2018-06-06 09:16:21 +0200] [19829] [INFO] Using worker: sync
[2018-06-06 09:16:21 +0200] [19832] [INFO] Booting worker with pid: 19832
[2018-06-06 09:16:22 +0200] [19829] [DEBUG] 1 workers
[2018-06-06 09:16:48 +0200] [19832] [DEBUG] GET /
[2018-06-06 09:17:19 +0200] [19829] [CRITICAL] WORKER TIMEOUT (pid:19832)
[2018-06-06 09:17:19 +0200] [19832] [INFO] Worker exiting (pid: 19832)
[2018-06-06 09:17:19 +0200] [19872] [INFO] Booting worker with pid: 19872
^C[2018-06-06 09:17:26 +0200] [19829] [INFO] Handling signal: int
[2018-06-06 09:17:26 +0200] [19872] [INFO] Worker exiting (pid: 19872)
[2018-06-06 09:17:26 +0200] [19829] [INFO] Shutting down: Master

~$ pip list
Package      Version
------------ -------
click        6.7    
Flask        1.0.2  
gunicorn     19.8.1 
itsdangerous 0.24   
Jinja2       2.10   
MarkupSafe   1.0    
pip          10.0.1 
setuptools   39.2.0 
Werkzeug     0.14.1 
wheel        0.31.1

@bigunyak 기본 시간 초과 때문이라고 생각합니다. 작업자는 30초 동안 침묵했습니다. http://docs.gunicorn.org/en/stable/settings.html#timeout

귀하의 로그에서,

[2018-06-05 14:57:16 +0200] [11232] [DEBUG] GET /
[2018-06-05 14:57:47 +0200] [11229] [CRITICAL] WORKER TIMEOUT (pid:11232)

[2018-06-06 09:16:48 +0200] [19832] [DEBUG] GET /
[2018-06-06 09:17:19 +0200] [19829] [CRITICAL] WORKER TIMEOUT (pid:19832)

동일한 것을 보고 있습니다. 동기화 작업자를 사용하여 요청을 제공하지 않는 경우에도 작업자가 시간 초과됩니다.
그런 의미에서 임계 수준 로그는 상당히 혼란스럽습니다.

이 문제를 해결할 수 있는 Gevent 작업자를 사용해 보십시오.

그런 의미에서 임계 수준 로그는 상당히 혼란스럽습니다.

정확히 그것은 내 원래 질문이었습니다. 예상되는 동작이라면 왜 심각한 오류가 발생합니까?
작업자를 다시 시작해야 하는 이유에 대한 배경 지식을 얻는 것도 좋을 것입니다. 아마도 이것이 설계 문서에 추가될 수 있을 것입니다.

저도 이것을 보고 있으며( examples/test.py with gunicorn test:app -b localhost:9595 --log-level=debug --timeout=5 를 사용하여 재현함) 임계 수준이 약간 혼란스럽다는 데 동의합니다. 디버그 수준으로 변경하는 것이 좋습니다. @benoitc @tilgovi 어떻게 생각하세요?

정보 수준이 조금 더 나을 수 있다고 생각합니다.

나는 Win10의 MSYS2와 동일했지만 마침내 해결할 수있었습니다.

...\gunicorn\workers\workertmp.py의 notify()에서는 원래 os.fchmod를 사용합니다. 그러나 MSYS에서는 작동하지 않습니다. os.fchmod 대신 os.utime을 사용했습니다. 코드를 따릅니다. 모든 플랫폼에서 작동할 수 있다고 생각합니다.

    def notify(self):
        try:
            self.spinner = (self.spinner + 1) % 2
            os.fchmod(self._tmp.fileno(), self.spinner)
            if PLATFORM.startswith('MSYS') :
                os.utime(self._tmp.fileno(), None)
        except AttributeError:
            # python < 2.6
            self._tmp.truncate(0)
            os.write(self._tmp.fileno(), b"X")

@berkerpeksag 요청이 발생하지 않기 때문에 작업자가 종료될 것으로 예상하지 않습니다. 이 오류는 작업자가 시간 초과까지 > 동안 바쁘게 유지된 경우에만 발생합니다. 따라서 오류가 중요합니다. 더 많은 사용 사례와 이러한 오류에 대한 응답을 제공하기 위해 문서를 개선해야 합니다.

작업자가 바쁘지 않을 때 오류가 계속 발생하면 다른 일이 발생하고 있으며 아마도 버그가 있는 것입니다.

[편집하다]
나에게도 같은 버그.
Django 1.10 / gunicorn 19.6.0 / Python 2.7.15 in python2.7-alpine on Debian 8.8 및 스톡 커널 3.16에서는 모두 잘 작동했습니다.
Django 1.11 및 gunicorn 19.8.1로 업데이트한 후 작업자가 [CRITICAL WORKER TIMEOUT]과 함께 부팅 시 계속 실패합니다.
gunicorn을 19.6.0으로 다운그레이드해도 문제가 해결되지 않습니다.
호스트 커널을 4.9.0(예정)으로 업데이트했고 작업자는 오류 없이 성공적으로 부팅되었습니다.
하지만:

• 우리는 4명의 노동자를 사용합니다
• Django 앱을 정확히 4번 호출하면 다음 호출이 시간 초과되어 로그에 [CRITICAL WORKER TIMEOUT]이 표시됩니다.
• linux top 명령은 4개의 gunicorn 프로세스가 상당히 높은 CPU 소비로 멈춘 것을 보여줍니다.

앱을 다시 온라인 상태로 만들 수 있는지 확인하기 위해 gunicorn gevent를 시도할 것입니다.

gevent와 함께 gunicorn을 사용해도 버그가 수정되지 않았습니다.

이 문제에 대한 업데이트가 있습니까?

@neocolor 가 MSYS에서 실제 버그를 식별한 것 같습니다. 별도의 문제가 될 수 있습니다.

@bigunyak 어떤 플랫폼에서 실행 중입니까? 간단한 예제로 재현을 시도했지만 위에 설명된 단계를 정확히 따라 수행할 수 없습니다. 이는 여러 프레임워크에서 프로덕션 환경에서 여러 응용 프로그램을 실행한 제 경험과 일치합니다. 내가 아는 한 근로자 알림 시스템은 최근에 변경되지 않았습니다. 내 플랫폼은 MacOS 10.13.6의 Python 3.7이지만 Python 2.7 및 3.6.5의 여러 애플리케이션에 대해 동기화 작업자와 함께 프로덕션 환경에서 Gunicorn을 실행하고 작업자를 차단하는 합법적으로 긴 요청이 있는 경우에만 작업자 시간 초과가 표시됩니다.

@Tberdy의 경우 : --worker-tmp-dir 를 tmpfs 파일 시스템 외부의 어딘가로 설정하려고 하면 어떻게 됩니까? 알파인 또는 도커 또는 조합이 작업자가 중재자에게 알리는 방식을 어떻게든 방해하는지 궁금합니다.

Docker 관련 tmpfs 문제는 #1388도 참조하세요.

나는이 문제가 있습니다.

저도 이 문제가 있습니다. 어제 밤까지 gunicorn sync가 완벽하게 작동했지만 보고를 시작했으며 gevent를 사용하는 작업자 시간 초과 [CRITICAL]이 내 문제를 해결하는 것 같지만 왜 이런 일이 발생했는지 알고 싶습니다.

@timoj58 @cjmash 이 문제에 대해 더 자세히 알려 주실 수 있습니까? 어떤 파일 시스템, OS에서 gunicorn(vm에서?, 옵션 ...)을 어떻게 실행하고 있습니까? 번식에 도움이 될 수 있는 ANthing은 매우 도움이 될 것입니다 :)

@benoitc kubernetes에서 내 Django 프로젝트를 시작하기 위해 gunicorn을 실행 중입니다. 내 gunicorn 인수는 --bind=$port --workers=7 --timeout=1200 --log-level=debug --access-logfile - error-logfile - "

내가 로그에서 얻는 오류

```E [2018-08-09 21:47:56 +0000] [13] [INFO] pid가 있는 부팅 작업자: 13

E [2018-08-09 21:47:56 +0000] [14] [INFO] pid: 14로 작업자 부팅

E [2018-08-09 21:47:56 +0000] [12] [INFO] pid가 12인 부팅 작업자

E [2018-08-09 21:47:56 +0000] [1] [DEBUG] 작업자 7명

E [2018-08-09 21:47:56 +0000] [11] [INFO] pid가 11인 작업자 부팅

E [2018-08-09 21:47:55 +0000] [10] [INFO] pid가 있는 작업자 부팅: 10

E [2018-08-09 21:47:55 +0000] [9] [INFO] pid: 9로 작업자 부팅

E [2018-08-09 21:47:55 +0000] [8] [INFO] pid가 8인 작업자 부팅

E [2018-08-09 21:47:55 +0000] [1] [INFO] 작업자 사용: 동기화

E [2018-08-09 21:47:55 +0000] [1] [INFO] 듣기: http://0.0.0.0 :4040 (1)

E [2018-08-09 21:47:55 +0000] [1] [DEBUG] Arbiter 부팅됨

E [2018-08-09 21:47:55 +0000] [1] [INFO] 기니콘 시작 19.7.1

E raw_paste_global_conf: []

전자 암호: TLSv1

E do_handshake_on_connect: 거짓

E suppress_ragged_eofs: 참

E ca_certs: 없음

전자 cert_reqs: 0

E SSL_버전: 2

전자 인증서 파일: 없음

E 키 파일: 없음

E proxy_allow_ips: ['127.0.0.1']

E proxy_protocol: 거짓

E on_exit:

E nworkers_changed:

E 작업자_종료:

E child_exit:

전자 우편 요청:

E 사전 요청:

E pre_exec:

E 작업자_중단:

E 작업자_int:

E post_worker_init:

전자 포스트_포크:

E pre_fork:

E when_ready:

E on_reload:

E on_starting:

E 붙여넣기: 없음

E 파이썬 경로: 없음

E default_proc_name: art.wsgi

E proc_name: 없음

E statsd_prefix:

E statsd_host: 없음

E enable_stdio_inheritance: 거짓

E syslog_facility: 사용자

E syslog_prefix: 없음

E 시스템 로그: 거짓

E syslog_addr: udp://localhost :514

E logconfig: 없음

E logger_class: gunicorn.glogging.Logger

E capture_output: 거짓

E 로그 수준: 디버그

E 오류 로그: -

E access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%( 처럼"

전자 액세스 로그: -

E forwarded_allow_ips: ['127.0.0.1']

E secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}

E tmp_upload_dir: 없음

E 초기 그룹: False

유마스크: 0

E 그룹: 0

전자 사용자: 0

E worker_tmp_dir: 없음

E pidfile: 없음

E raw_env: []

E 데몬: 거짓

E chdir: /usr/src/app

E sendfile: 없음

E preload_app: 거짓

E check_config: 거짓

E 분출: 거짓

E reload_engine: 자동

E 재장전: 거짓

E limit_request_field_size: 8190

E limit_request_fields: 100

E limit_request_line: 4094

전자 킵얼라이브: 2

E Graceful_timeout: 30

전자 타임아웃: 1200

E max_requests_jitter: 0

E max_requests: 0

E 작업자_연결: 1000

E 스레드: 1

E worker_class: 동기화

전자 작업자: 7

전자 백로그: 2048

전자 바인드: ['0.0.0.0:4040']

전자 구성: 없음

E [2018-08-09 21:47:55 +0000] [1] [DEBUG] 현재 구성:

I 신청할 마이그레이션이 없습니다.

I 마이그레이션 실행:

I 모든 마이그레이션 적용: admin, auth, contenttypes, core, 대시보드, jet, oauth2_provider, session

I 수행할 작업:

E [2018-08-09 21:47:20 +0000] [13] [INFO] 작업자 종료 (pid: 13)

E os.path.dirname(os.path.dirname(__file__)), '.env'))

E /usr/src/app/art/wsgi.py:19: UserWarning: 읽지 않음 /usr/src/app/.env - 존재하지 않습니다.

E [2018-08-09 21:47:00 +0000] [21] [INFO] pid: 21로 작업자 부팅

E [2018-08-09 21:47:00 +0000] [1] [INFO] 처리신호 : 기간

E [2018-08-09 21:46:35 +0000] [12] [INFO] pid: 12로 작업자 부팅

E [2018-08-09 21:46:34 +0000] [13] [INFO] pid가 13인 부팅 작업자

E [2018-08-09 21:46:34 +0000] [11] [INFO] pid가 11인 작업자 부팅

E [2018-08-09 21:46:34 +0000] [1] [DEBUG] 작업자 7명

E [2018-08-09 21:46:34 +0000] [10] [INFO] pid가 10인 작업자 부팅

E [2018-08-09 21:46:34 +0000] [9] [INFO] pid가 9인 작업자 부팅

E [2018-08-09 21:46:34 +0000] [8] [INFO] pid가 8인 작업자 부팅

E [2018-08-09 21:46:34 +0000] [7] [INFO] pid가 7인 작업자 부팅

E [2018-08-09 21:46:34 +0000] [1] [INFO] 작업자 사용: 동기화

E [2018-08-09 21:46:34 +0000] [1] [INFO] 듣기: http://0.0.0.0 :4040 (1)

E [2018-08-09 21:46:34 +0000] [1] [DEBUG] Arbiter 부팅됨

E [2018-08-09 21:46:34 +0000] [1] [INFO] 기니콘 시작 19.7.1

E raw_paste_global_conf: []

전자 암호: TLSv1

E do_handshake_on_connect: 거짓

E suppress_ragged_eofs: 참

E ca_certs: 없음

전자 cert_reqs: 0

E SSL_버전: 2

전자 인증서 파일: 없음

E 키 파일: 없음

E proxy_allow_ips: ['127.0.0.1']

E proxy_protocol: 거짓

E on_exit:

E nworkers_changed:

E 작업자_종료:

E child_exit:

전자 우편 요청:

E 사전 요청:

E pre_exec:

E 작업자_중단:

E 작업자_int:

E post_worker_init:

전자 포스트_포크:

E pre_fork:

E when_ready:

E on_reload:

E on_starting:

E 붙여넣기: 없음

E 파이썬 경로: 없음

E default_proc_name: art.wsgi

E proc_name: 없음

E statsd_prefix:

E statsd_host: 없음

E enable_stdio_inheritance: 거짓

E syslog_facility: 사용자

E syslog_prefix: 없음

E 시스템 로그: 거짓

E syslog_addr: udp://localhost :514

E logconfig: 없음

E logger_class: gunicorn.glogging.Logger

E capture_output: 거짓

E 로그 수준: 디버그

E 오류 로그: -

E access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%( 처럼"

전자 액세스 로그: -

E forwarded_allow_ips: ['127.0.0.1']

E secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}

E tmp_upload_dir: 없음

E 초기 그룹: False

유마스크: 0

E 그룹: 0

전자 사용자: 0

E worker_tmp_dir: 없음

E pidfile: 없음

E raw_env: []

E 데몬: 거짓

E chdir: /usr/src/app

E sendfile: 없음

E preload_app: 거짓

E check_config: 거짓

E 분출: 거짓

E reload_engine: 자동

E 재장전: 거짓

E limit_request_field_size: 8190

E limit_request_fields: 100

E limit_request_line: 4094

전자 킵얼라이브: 2

E Graceful_timeout: 30

전자 타임아웃: 1200

E max_requests_jitter: 0

E max_requests: 0

E 작업자_연결: 1000

E 스레드: 1

E worker_class: 동기화

전자 작업자: 7

전자 백로그: 2048

전자 바인드: ['0.0.0.0:4040']

전자 구성: 없음

E [2018-08-09 21:46:34 +0000] [1] [DEBUG] 현재 구성:

```

이번에는 문제를 재현하기 위해 약간 고심했지만 최신 gunicorn 버전 19.9.0에는 여전히 있습니다.
그것을 재현하는 단계는 이 게시물 에서 설명한 것과 정확히 동일합니다.
내 시스템은 Arch Linux x86_64 GNU/Linux(커널 4.17.2-1-ARCH), Python 3.6.5입니다.
다음은 새로운 로그 추적입니다.

~$ gunicorn -b 0.0.0.0:5000 --log-level=debug hello
[2018-08-10 09:48:40 +0200] [23114] [DEBUG] Current configuration:
  config: None
  bind: ['0.0.0.0:5000']
  backlog: 2048
  workers: 1
  worker_class: sync
  threads: 1
  worker_connections: 1000
  max_requests: 0
  max_requests_jitter: 0
  timeout: 30
  graceful_timeout: 30
  keepalive: 2
  limit_request_line: 4094
  limit_request_fields: 100
  limit_request_field_size: 8190
  reload: False
  reload_engine: auto
  reload_extra_files: []
  spew: False
  check_config: False
  preload_app: False
  sendfile: None
  reuse_port: False
  chdir: /home/dima/lerning/python/modules/gunicorn
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1000
  group: 985
  umask: 0
  initgroups: False
  tmp_upload_dir: None
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  forwarded_allow_ips: ['127.0.0.1']
  accesslog: None
  disable_redirect_access_to_syslog: False
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  errorlog: -
  loglevel: debug
  capture_output: False
  logger_class: gunicorn.glogging.Logger
  logconfig: None
  logconfig_dict: {}
  syslog_addr: udp://localhost:514
  syslog: False
  syslog_prefix: None
  syslog_facility: user
  enable_stdio_inheritance: False
  statsd_host: None
  statsd_prefix: 
  proc_name: None
  default_proc_name: hello
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f5f8b9dad08>
  on_reload: <function OnReload.on_reload at 0x7f5f8b9dae18>
  when_ready: <function WhenReady.when_ready at 0x7f5f8b9daf28>
  pre_fork: <function Prefork.pre_fork at 0x7f5f8b4ec0d0>
  post_fork: <function Postfork.post_fork at 0x7f5f8b4ec1e0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f5f8b4ec2f0>
  worker_int: <function WorkerInt.worker_int at 0x7f5f8b4ec400>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f5f8b4ec510>
  pre_exec: <function PreExec.pre_exec at 0x7f5f8b4ec620>
  pre_request: <function PreRequest.pre_request at 0x7f5f8b4ec730>
  post_request: <function PostRequest.post_request at 0x7f5f8b4ec7b8>
  child_exit: <function ChildExit.child_exit at 0x7f5f8b4ec8c8>
  worker_exit: <function WorkerExit.worker_exit at 0x7f5f8b4ec9d8>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f5f8b4ecae8>
  on_exit: <function OnExit.on_exit at 0x7f5f8b4ecbf8>
  proxy_protocol: False
  proxy_allow_ips: ['127.0.0.1']
  keyfile: None
  certfile: None
  ssl_version: 2
  cert_reqs: 0
  ca_certs: None
  suppress_ragged_eofs: True
  do_handshake_on_connect: False
  ciphers: TLSv1
  raw_paste_global_conf: []
[2018-08-10 09:48:40 +0200] [23114] [INFO] Starting gunicorn 19.9.0
[2018-08-10 09:48:40 +0200] [23114] [DEBUG] Arbiter booted
[2018-08-10 09:48:40 +0200] [23114] [INFO] Listening at: http://0.0.0.0:5000 (23114)
[2018-08-10 09:48:40 +0200] [23114] [INFO] Using worker: sync
[2018-08-10 09:48:40 +0200] [23117] [INFO] Booting worker with pid: 23117
[2018-08-10 09:48:40 +0200] [23114] [DEBUG] 1 workers
[2018-08-10 09:48:45 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:48:54 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:00 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:18 +0200] [23117] [DEBUG] Closing connection. 
[2018-08-10 09:49:18 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:23 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:37 +0200] [23117] [DEBUG] Closing connection. 
[2018-08-10 09:49:37 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:49:50 +0200] [23117] [DEBUG] Closing connection. 
[2018-08-10 09:51:11 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:51:13 +0200] [23117] [DEBUG] GET /
[2018-08-10 09:51:43 +0200] [23114] [CRITICAL] WORKER TIMEOUT (pid:23117)
[2018-08-10 09:51:43 +0200] [23117] [INFO] Worker exiting (pid: 23117)
[2018-08-10 09:51:44 +0200] [23229] [INFO] Booting worker with pid: 23229

테스트하기 전에 Chromium에서 http://0.0.0.0 :5000/을 치고 있었습니다.
아래는 정확한 환경을 볼 수 있도록 Pipfile과 Pipfile.lock의 내용입니다.

• 핍파일

[[source]]
url = "https://pypi.org/simple"
verify_ssl = true
name = "pypi"

[packages]
flask = "*"
gunicorn = "*"

[dev-packages]

[requires]
python_version = "3.6"

• Pipfile.lock

{
    "_meta": {
        "hash": {
            "sha256": "81cb5d5f0b11719d8d9c5ec9cc683fdcf959c652fda256d5552a82d0f459a99c"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.6"
        },
        "sources": [
            {
                "name": "pypi",
                "url": "https://pypi.org/simple",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "click": {
            "hashes": [
                "sha256:29f99fc6125fbc931b758dc053b3114e55c77a6e4c6c3a2674a2dc986016381d",
                "sha256:f15516df478d5a56180fbf80e68f206010e6d160fc39fa508b65e035fd75130b"
            ],
            "version": "==6.7"
        },
        "flask": {
            "hashes": [
                "sha256:2271c0070dbcb5275fad4a82e29f23ab92682dc45f9dfbc22c02ba9b9322ce48",
                "sha256:a080b744b7e345ccfcbc77954861cb05b3c63786e93f2b3875e0913d44b43f05"
            ],
            "index": "pypi",
            "version": "==1.0.2"
        },
        "gunicorn": {
            "hashes": [
                "sha256:aa8e0b40b4157b36a5df5e599f45c9c76d6af43845ba3b3b0efe2c70473c2471",
                "sha256:fa2662097c66f920f53f70621c6c58ca4a3c4d3434205e608e121b5b3b71f4f3"
            ],
            "index": "pypi",
            "version": "==19.9.0"
        },
        "itsdangerous": {
            "hashes": [
                "sha256:cbb3fcf8d3e33df861709ecaf89d9e6629cff0a217bc2848f1b41cd30d360519"
            ],
            "version": "==0.24"
        },
        "jinja2": {
            "hashes": [
                "sha256:74c935a1b8bb9a3947c50a54766a969d4846290e1e788ea44c1392163723c3bd",
                "sha256:f84be1bb0040caca4cea721fcbbbbd61f9be9464ca236387158b0feea01914a4"
            ],
            "version": "==2.10"
        },
        "markupsafe": {
            "hashes": [
                "sha256:a6be69091dac236ea9c6bc7d012beab42010fa914c459791d627dad4910eb665"
            ],
            "version": "==1.0"
        },
        "werkzeug": {
            "hashes": [
                "sha256:c3fd7a7d41976d9f44db327260e263132466836cef6f91512889ed60ad26557c",
                "sha256:d5da73735293558eb1651ee2fddc4d0dedcfa06538b8813a2e20011583c9e49b"
            ],
            "version": "==0.14.1"
        }
    },
    "develop": {}
}

참고로 저는 이 실패를 다음과 같이 매우 정기적으로 보고 있습니다.

nohup gunicorn -w 8 --access-logfile=- --bind 127.0.0.1:5000 wsgi &

나는 단지 wsgi.py가 있습니다.

from chart_api import application
if __name__ == "__main__":
    application.run()

내가 시도하거나 실험하기를 원하는 것이 있거나 내가 확인하기를 원하는 로그에 세부 사항이 있으면 알려주십시오. GCP VM에서 플라스크를 실행하고 있습니다.

늦은 답변 죄송합니다. 나는 그것을 실행하고있다

gunicorn --log-file=/home/ubuntu/log/gunicorn.log predictor_ api:app -b localhost:5000 &

나는 gevent 설정 등을 사용했지만 문제를 해결하기 위해 필요한 것의 디자인을 변경했습니다. 따라서 위의 기본 설정도 실패했지만 이것은 gevent가 없는 것으로 예상됩니다.

파이썬 버전 3.6
환경: aws tensorflow_p36 최적화(우분투)
nginx는 플라스크 앱을 실행하는 gunicorn 앞에 앉습니다.

플라스크 버전 1.0.2
nginx 버전 1.10.3
gunicorn 버전 19.9.0

이로 인해 발생할 수 있는 경우를 대비하여 nginx 시간 초과도 변경했습니다.

gunicorn 서버와 동일한 문제에 직면

# gunicorn ApplicationServer :app -b 0.0.0.0:6001 -w 8 --threads 4 --backlog 2048 \
# --timeout 120 --graceful-timeout 60 --access-logfile logs/access.log \

--error-logfile 로그/error.log --log-level=info

플라스크==0.12.1
gunicorn==19.7.1

위의 명령으로 서버를 시작하면 내 시스템이 잠시 정지되고 작업자 pid가 계속 부팅되지만 시간 제한을 120초로 유지하고 서버가 단일 요청을 수락하지 않습니다.

이 문제에 대한 업데이트가 있습니까? 나는 같은 문제가있다

[중요] 작업자 시간 초과

Docker 이미지에서 이것을 성공적으로 재현한 사람이 있는지 궁금하십니까?

또한 gunicorn -k gevent --threads 4로 시작하는 기존 애플리케이션에서 datadog의 ddtrace-run 작업자를 구현하려고 할 때 이것을 봅니다.

나도 본 적 없는 SystemExit의 웃긴 자취...
[2018-11-07 11:11:50 +0000] [15987] [INFO] Booting worker with pid: 15987 [2018-11-07 11:11:50 +0000] [15977] [DEBUG] 1 workers [2018-11-07 11:12:20 +0000] [15977] [CRITICAL] WORKER TIMEOUT (pid:15987) Exception SystemExit: 1 in <bound method LibevLoop._loop_will_run of <cassandra.io.libevreactor.LibevLoop object at 0x7f3cb66d4a50>> ignored

작업자 수와 스레드 수를 일치시켜 이 문제를 해결할 수 있습니다.

workers = (2 * cpu_count) + 1 을 설정했고 스레드를 설정하지 않았습니다.

threads = workers 변경하면 모든 것이 제대로 작동하기 시작했습니다. 만일의 경우를 대비하여 이것이 누군가에게 도움이 된다면.

이것이 지금의 모습이다.

def run(host='0.0.0.0', port=8080, workers=1 + (multiprocessing.cpu_count() * 2)):
    """Run the app with Gunicorn."""

    if app.debug:
        app.run(host, int(port), use_reloader=False)
    else:
        gunicorn = WSGIApplication()
        gunicorn.load_wsgiapp = lambda: app
        gunicorn.cfg.set('bind', '%s:%s' % (host, port))
        gunicorn.cfg.set('workers', workers)
        gunicorn.cfg.set('threads', workers)
        gunicorn.cfg.set('pidfile', None)
        gunicorn.cfg.set('worker_class', 'sync')
        gunicorn.cfg.set('keepalive', 10)
        gunicorn.cfg.set('accesslog', '-')
        gunicorn.cfg.set('errorlog', '-')
        gunicorn.cfg.set('reload', True)
        gunicorn.chdir()
        gunicorn.run()

AWS Elastic Beanstalk에서 단일 Docker 컨테이너로 Django를 실행할 때 이 문제가 발생했습니다. 내 EC2 인스턴스가 내 RDS 인스턴스와 통신할 수 있도록 보안 그룹을 수정하여 문제를 해결했습니다. 나는 이것이 이 문제에 대한 99%의 사람들을 위한 해결책이 아닐 수도 있다는 것을 알고 있지만, 다른 사람들이 이 토끼굴에 빠지는 데 시간을 낭비하지 않도록 돕기 위해 이 메모를 남깁니다.

제 경우에는 systemctl daemon-reload 수행하여 문제가 해결되었습니다.
간단히 말해서 30초의 기본 시간 제한을 알고 있었지만 변경 사항을 서비스에 적용하기 위해 시스템 데몬을 다시 로드해야 한다는 것을 알 때까지 변경할 수 없었습니다.

@bigunyak @benoitc @tilgovi
긴 구글 구스 추적과 몇 가지 실험 후에 나는 이 문제의 근본 원인이 크롬 "사전 연결/예측 서비스"(Chrome과 Chromium 모두에서 기본적으로 활성화됨)라고 생각합니다.

@jeiting 은 이 문제에 대해 잘 썼습니다.
https://hackernoon.com/chrome-preconnect-breaks-singly-threaded-servers-95944be16400
추가 읽기:
https://github.com/corydolphin/flask-cors/issues/147
https://github.com/pallets/flask/issues/2169

TLDR
어떤 경우에는 Chrome/Chromium이 열리고 "빈" TCP 연결이 유지됩니다(즉, 곧 다른 리소스를 가져올 것이라고 예측). "빈" TCP 연결이 먼저 gunicorn 서버에 도달하면 "빈" 요청을 처리하는 작업자가 시간 초과될 때까지 크롬의 후속 "실제" 요청이 "빈" 요청 뒤에 멈출 수 있습니다. 이는 gunicorn에서 단일 동기화 작업자만 실행하는 경우 발생할 가능성이 더 큽니다. 그러나 내 실험에 따르면 여러 동기화 작업자를 실행하는 경우에도 발생할 수 있습니다.

내 환경

• 내 기본 OS는 Ubuntu 17입니다.
• 로컬 도커 컨테이너에서 실행 중인 나머지 API가 있습니다. Dockefile의 관련 라인

FROM ubuntu:18.04
...
RUN pip3 install Flask==1.0.2
RUN pip3 install gunicorn==19.9.0
RUN pip3 install flask-cors==3.0.6
......

• 3개의 브라우저가 설치되어 있습니다: Firefox 61.0.1, Chromium 67.0.3396.99, Chrome 70.0.3538.102
• 다른 포트의 다른 도커 컨테이너에서 제공되는 반응 앱이 있습니다.
• 반응 앱은 내 API에 대한 CORS AJAX 요청을 만듭니다(자바스크립트는 다른 로컬 호스트 포트로 API 호출을 보내는 동안 하나의 로컬 호스트 포트에서 제공되기 때문에 CORS 요청임).
• 내 실험에서 항상 "차단"되는 요청은 CORS OPTIONS 요청입니다(브라우저에서 POST 요청을 수행할 수 있는 권한을 요청하기 위해 트리거됨). 브라우저가 POST 호출로 후속 조치를 취할 가능성이 있기 때문에 OPTIONS 호출로 예측 연결을 시도하는 것이 논리적으로 보입니다.

실험 1
Gunicorn 구성: 동기화 작업자 1개(기본 30초 제한 시간)

Firefox: 거의 모든 반응 페이지 로드에서 CORS OPTIONS 요청이 5초 동안 차단된 다음 성공합니다.
Chromium: 모든 반응 페이지 로드에서 CORS OPTIONS 요청이 1.5분 동안 차단됩니다!!!! 그리고 성공합니다.
Chromium(예측 서비스 비활성화됨): 모든 것이 잘 로드됨
Chrome: 모든 것이 잘 로드됩니다.

실험 2
Gunicorn 구성: 4개의 동기화 작업자(기본 30초 제한 시간)

Firefox: 모든 것이 잘 로드됩니다.
Chromium: 세 번째 반응 페이지 로드마다 CORS OPTIONS 요청이 30초 동안 차단된 다음 성공합니다.
Chromium(예측 서비스 비활성화됨): 모든 것이 잘 로드됨
Chrome: 모든 것이 잘 로드됩니다.

실험 3
Gunicorn 구성: 8개의 동기화 작업자(기본 30초 제한 시간)

Firefox: 모든 것이 잘 로드됩니다.
Chromium: 모든 것이 잘 로드됩니다.
Chrome: 모든 것이 잘 로드됩니다.

실험 4
threaded=True 플라스크 개발 서버 실행

Firefox: 모든 것이 잘 로드됩니다.
Chromium: 모든 것이 잘 로드됩니다.
Chrome: 모든 것이 잘 로드됩니다.

실험 요약

• 파이어폭스에도 예측 서비스가 있는 것 같지만 더 우아해 보인다. (실험 1)
• Chromium은 "예측" 연결을 생성하는 데 가장 공격적으로 보입니다. OPTIONS 요청 중에 최대 3-4개의 "예측" 연결을 시작하는 것으로 보입니다(실험 1 및 2).
• 놀랍게도 Chrome에도 예측 서비스가 활성화되어 있지만 실험에서 문제가 발생하지 않았습니다("예측" 연결의 순서 또는 수가 Chromium과 다를 수 있음).

해결책
프로덕션에서: 가장 쉬운 수정은 nginx를 gunicorn 앞에 두는 것입니다. nginx가 이 문제를 해결하는 이유를 이해하려면 이를 설명하는 멋진 기사가 있습니다. https://www.brianstorti.com/the-role-of-a-reverse-proxy-to-protect-your-application-against - 느린 클라이언트/

In dev: 가장 쉬운 수정은 threaded=True flask dev 서버를 실행하는 것입니다. 또는 Chrome/Chromium에서 예측 서비스를 비활성화할 수 있습니다.

gunicorn 디버그 개선 사항
앞으로 이와 같은 문제를 디버그하는 데 도움이 되도록 동기화 작업자에서 select() 및 accept() 호출 옆에 디버그 로그 문을 추가하는 것이 좋습니다.
https://github.com/benoitc/gunicorn/blob/e974f30517261b2bc95cfb2017a8688f367c8bf3/gunicorn/workers/sync.py#L26
https://github.com/benoitc/gunicorn/blob/e974f30517261b2bc95cfb2017a8688f367c8bf3/gunicorn/workers/sync.py#L34
이것은 작업자가 새 TCP 연결을 수락했지만 데이터를 수신하지 않았음을 보여줍니다.

@asnisarenko 슈퍼 쓰기, 감사합니다. #1929는 단일 스레드 서버에서 유사한 증상을 나타내는 느린 클라이언트의 또 다른 특이한 경우입니다. 이 경우 TLS가 아닌 포트에 대한 TLS 핸드셰이크는 합리적인 헤더를 빠르게 보내지 못하기 때문에 쓰기가 느린 클라이언트처럼 보입니다. .

단일 스레드 동기화 작업자의 경우 합리적인 시간 내에 모든 헤더는 아닐지라도 첫 번째 요청 헤더 행을 보내지 못하는 클라이언트에 대해 새로운 조정 가능, 적극적인 클라이언트 삭제가 필요할 것이므로 Gunicorn일 수 있습니다.

앱에서 이런 일이 발생하면 임시 진단 코드를 추가할 수 있습니다.

def trace_on_abort():
    import signal
    import traceback

    def print_trace(sig, frame):
        print(''.join(traceback.format_stack(frame)))

    signal.signal(signal.SIGABRT, print_trace)

앱이 중단된 위치가 표시되기를 바랍니다.

예를 들어, 어떻게 든로 관리 import flask 전에 gevent.monkey.patch_all() 와 나의 플라스크의 app._before_request_lock 아닌 gevent 잠금 었죠 (즉, 일반 패치 threading.Lock ). 이러한 경우 앱 시작 시 두 개의 요청이 연속적으로 발생하면 앱이 중단됩니다(두 번째 요청은 전체 스레드를 잠급니다). 그러나 이것은 내 버그였으며 귀하의 버그는 다를 수 있습니다.

@asnisarenko 왜 중단이 발생하는지 잘 모르겠습니다. 모든 작업자가 협력하여 수천 개의 연결을 처리할 수 있기 때문에 연결당 작업자가 필요하지 _않습니다_(처리 코드가 CPU를 독점하지 않거나 전체 스레드를 잠그지 않는 한). 특히, 브라우저가 요청을 중단하면 소켓에서 gunicorn read() 가 있을 때 그린렛을 차단하지만 read 는 원숭이 패치되어야 하므로 다른 그린렛.

@iconst
이 문제는 기본 구성으로 gunicorn을 실행하는 것에 대한 것입니다. 기본 작업자 클래스는 sync http://docs.gunicorn.org/en/stable/settings.html#worker -class입니다.

sync 작업자는 pre-fork 모델을 사용하고 각 작업자는 한 번에 하나의 TCP 연결/요청을 처리합니다.

이 문제의 원인이 무엇인지 모르지만 기본 sync 작업자 유형에서 eventlet 하면 문제가 해결되었습니다.

CMD pipenv run gunicorn webapp -b 0.0.0.0:8080 -k eventlet

행운을 빕니다.

이것은 나에게만 도움이 될 수 있지만 내 쪽에서 이 문제를 디버깅하는 데 7시간이 걸렸으므로(EC2의 Docker에서 실행되는 Flask/Gunicorn 앱) 이 골칫거리를 소수의 사람들에게 덜어줄 수 있다면 작은 승리입니다.

컨테이너 메모리 제한이 너무 낮습니다.

앞으로 메모리 누수가 발생하면 메모리 제한을 더 높게 설정하려고 하지만 현재로서는 제한이 없습니다.

감사 해요

def trace_on_abort():
    import signal
    import traceback

    def print_trace(sig, frame):
        print(''.join(traceback.format_stack(frame)))

    signal.signal(signal.SIGABRT, print_trace)

당신은 나를 많이 도와주세요. 에후))))

이 trace_on_abort() 방법은 어디로 갑니까? 앱 코드 파일에서? 주석이 필요합니까?

@mattg-vbt 디버그해야 할 때 앱 시작 부분에 이것을 추가하고 디버깅이 끝나면 제거하십시오.

@ikonst 이것을 내 앱에 추가했지만 적중하는 것을 보지 못했습니다. 작업자 시간 초과가 발생하지만 이 방법은 적중되지 않습니다.

@mattg-vbt kill -ABRT $pid 를 수행하여 print_trace 함수가 호출되는 것을 볼 수 있습니까? (이 아이디어는 작업자가 시간 초과될 때 werkzeug에서 SIGABRT를 얻을 수 있다는 것입니다. 하지만 먼저 호출되었는지 확인하겠습니다.)

@asnisarenko 우리 사이에 덜 정통한 경우 procfile을 어떻게 업데이트합니까?

web gunicorn app:app -k gevent --worker-connections 1000 ?

@SumNeuron
동기화 작업자 대신 gevent 작업자를 사용하는 경우 이 문제가 발생하지 않아야 합니다. 따라서 게시 한 명령이 괜찮은 것 같습니다.

초기화할 때만 gevent 작업자와 함께 이 문제가 발생합니다. 앱을 시작하기 전에 일부 작업을 처리하기 때문에 약간 성가신 일입니다. 그러나 지금은 높은 시간 제한을 설정하고 있습니다.
재현 가능한 테스트 리포지토리를 여기에 게시했습니다. https://github.com/zamponotiropita/test-gunicorn-worker-timeout -> test_0 실패, test_1 및 test_2 통과

@zamponotiropita 포크하기 전에 작업자별 또는 앱별로 수행하시겠습니까?

@ikonst run.sh 실행 파일을 확인하십시오. 작업자당입니다. 문제는 미리 로드할 때 발생하지 않았지만 미리 로드할 때 데이터베이스에 연결하는 데 문제가 있었습니다. 앱 개체(데이터베이스 연결과 함께)가 분기할 때 복사되고 프로세스를 전달하기 때문입니다. -> 내 데이터베이스가 처리할 수 없습니다. 마스터와 작업자의 동일한 연결 및 해결 방법을 찾을 수 없습니다.

비슷한 문제가 있습니다. Flask를 사용하여 즉석에서 많은 데이터를 생성하려고 합니다.
이 방법은 --timeout 에 설정된 값이 만료된 후 작업자가 시간 초과되기 때문에 실패합니다. 재현할 수 있는 최소한의 예:

test_gunicorn_timeout.py

import flask
from time import sleep


app = flask.Flask(__name__)


@app.route('/')
def gunicorn_timeout():
    def generator():
        for _ in range(10):
            yield b'Yet another line...'
            sleep(2)
    return flask.Response(generator(), mimetype='text/plain')

그런 다음 gunicorn --timeout 10 test_gunicorn_timeout:app 하고 10초 후에 localhost:8000 요청하면
[CRITICAL] WORKER TIMEOUT .

또한 -k gevent 및 -k eventlet 실행을 시도했지만 아무 것도 변경되지 않았습니다.

저는 윈도우 10 프로를 쓰고 있습니다. 도커 작성으로
gunicorn app -b 0.0.0.0:8000 -k gevent
내 파이썬 컨테이너에 gevent를 설치하여 나를 위해 일했습니다.
제벤트 설치 방법

그런 다음 gunicorn --timeout 10 test_gunicorn_timeout:app 하고 10초 후에 localhost:8000 요청하면
[CRITICAL] WORKER TIMEOUT .

또한 -k gevent 및 -k eventlet 실행을 시도했지만 아무 것도 변경되지 않았습니다.

@ltskv

[CRITICAL] WORKER TIMEOUT 문제에 대한 해결책을 찾았습니까?

heroku(gunicorn 사용)에 배포하려는 플라스크 스트리밍 엔드포인트에 비슷한 문제가 있습니다. 거기에서 프록시 프론트엔드는 일부 데이터가 30초 이내에 전송되는 한 연결을 유지해야 하지만 여전히 실행 중이고 데이터를 생성하고 있음에도 30초 이내에 완료되지 않으면 gunicorn이 프로세스를 종료하는 것처럼 보입니다.

gunicorn 문서는 이 시점에서 나에게 완전히 명확하지 않습니다. --timeout의 경우 Workers silent for more than this many seconds are killed and restarted. 라고 표시되지만 작업자는 여전히 데이터를 생성하지만 30초 후에 사망하는 것 같습니까?

gunicorn 문서는 이 시점에서 나에게 완전히 명확하지 않습니다. --timeout의 경우 이 몇 초 이상 침묵하는 작업자가 종료되고 다시 시작됩니다. 근데 워커들이 데이터를 생산하는데 30초가 지나면 죽는거 같은데요?

문서를 개선해야 한다는 @kurt-hictic. 묵음이란 임시 파일을 통해 작업자와 통신하는 중재자 프로세스의 관점에서 침묵을 의미합니다. 작업자가 데이터를 보내는 중이면 해당 파일을 업데이트하지 않습니다. 중재자의 관점에서 작업자는 하트비트를 놓치고 있습니다.

#1974도 참조하십시오.

다른 작업자가 요청을 처리할 때에도 임시 파일을 하트비트하므로 기본 작업자가 아닌 다른 작업자를 사용하는 동기 작업자는 스트리밍 큰 본문 문제를 완화해야 합니다.

@kurt-hectic -k gevent 옵션을 다시 한 번 확인하고 생성기 반복 사이에 sleep(0) 삽입했는데 실제로 효과가 있었습니다. 나는 질문을 게시했지만).

--시간 초과=5

이것이 이 문제의 가장 일반적인 원인입니다.

내 솔루션이 도움이 되기를 바랍니다. 나는 며칠 전에 이 중요한 작업자 시간 초과 문제를 만났고 몇 가지 솔루션을 시도했습니다. 이제 잘 작동합니다.

내 이해와 해결책은 다음과 같습니다.

1. gunicorn에서 미리 로드해 보세요.

서비스를 시작하기 위해 tensorflow 백엔드와 같은 패키지를 로드하는 데 더 많은 시간이 필요하기 때문에 작업자를 부팅하지 못합니다. 따라서 느린 앱 부팅 시간이 발생하면 gunicorn에서 사전 로드 옵션을 활성화해 보십시오(https://devcenter.heroku.com/articles/python-gunicorn#advanced-configuration 참조).

gunicorn hello:app --preload

1. gunicorn의 시간 초과를 늘리십시오.

기본 시간 초과는 30초입니다. 애플리케이션이 API를 완료하는 데 실제로 많은 시간이 필요한 경우 시간 초과를 늘리십시오.

gunicorn hello:app --timeout 10

그러나 내 관점에서 볼 때 API가 완료하는 데 1분 이상이 필요한 경우에는 의미가 없습니다. 그렇다면 코드에서 약간의 발전을 시도하십시오.

1. k8을 사용하는 경우 yaml에서 컨테이너/이미지에 대한 timeoutSeconds를 설정할 수도 있습니다.

나는 오늘 같은 문제에 직면했다. 제 경우에는 API가 데이터를 계산하고 클라이언트로 반환하는 데 약 1분이 소요되어 CRITICAL WORKER TIMEOUT 오류가 발생했습니다. 나는 gunicorn에 대한 시간 초과 플래그를 1분 이상으로 늘려 문제를 해결했습니다. 작동했지만 문제가 다시 발생하는 것을 보지 못했습니다. 도움이 되었기를 바랍니다. 나는 uvicorn.workers.UvicornWorker를 사용하고 있습니다.

gnuicorn에 작업자를 추가하여 이 문제를 해결했습니다.

web: gunicorn --workers=3 BlocAPI:app --log-file -

이유를 모르겠어.

교착 상태가 발생했나요? 앱이 자체적으로 요청을 합니까?

2020년 1월 5일 일요일 10:52 alpinechicken에서 알림 @github.com이 작성했습니다.

gnuicorn에 작업자를 추가하여 이 문제를 해결했습니다.

웹: gunicorn --workers=3 BlocAPI:app --log-file -

이유를 모르겠어.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAAEQJVQRCW3C63EZJWIN5DQ4G3WTA5CNFSM4FDLD5PKYY3PNVWWissueK3TUL52HS4DFVEXG43VMVBW63
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAAEQJXZM4NLK56DZMFSZALQ4G3WTANCNFSM4FDLD5PA
.

예, 한 경로가 다른 경로를 호출합니다. 그게 나쁜가요?

이는 최소한 두 명의 작업자가 필요하다는 것을 의미합니다. 그렇지 않으면 서버가
이중 자물쇠. 요청은 서버가 두 번째 응답에 응답할 때까지 대기합니다.
요청(대기열에 있음).

작업자당 하나의 동시 요청을 받습니다.

2020년 1월 6일 월요일, 02:45 alpinechicken, [email protected] 작성:

예, 한 경로가 다른 경로를 호출합니다. 그게 나쁜가요?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAAEQJSFEFBBI6AMZJCM4C3Q4KLOJA5CNFSM4FDLD5PKYY3PNVWWK3TUL52HS4DFVEXG43VMXVW63LNMV
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAAEQJXTCPOFIZJU5PUPOODQ4KLOJANCNFSM4FDLD5PA
.

아 이해가 됩니다. 감사 해요!

2020년 1월 7일 화요일 오전 6시 23분에 bobf [email protected]에서 다음과 같이 썼습니다.

이는 최소한 두 명의 작업자가 필요하다는 것을 의미합니다. 그렇지 않으면 서버가
이중 자물쇠. 요청은 서버가 두 번째 응답에 응답할 때까지 대기합니다.
요청(대기열에 있음).

작업자당 하나의 동시 요청을 받습니다.

2020년 1월 6일 월요일, 02:45 alpinechicken, [email protected] 작성:

예, 한 경로가 다른 경로를 호출합니다. 그게 나쁜가요?

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
<
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAAEQJSFEFBBI6AMZJCM4C3Q4KLOJA5CNFSM4FDLD5PKYY3PNVWWK3TUL52HS4DFVREXG43VMXHJ63LDNLOX
,
또는 구독 취소
<
https://github.com/notifications/unsubscribe-auth/AAAEQJXTCPOFIZJU5PUPOODQ4KLOJANCNFSM4FDLD5PA

.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/1801?email_source=notifications&email_token=AAH2WRPVPVO2EJ53BKQW5B3Q4OHLRA5CNFSM4FDLD5PKYY3PNVWQWK3TUL52HS4DFVEXG43NVMVBW
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAH2WRM2LLIB4O6OHCU5UG3Q4OHLRANCNFSM4FDLD5PA
.

작업자 클래스', '동기화')

작업자 수와 스레드 수를 일치시켜 이 문제를 해결할 수 있습니다.

workers = (2 * cpu_count) + 1 을 설정했고 스레드를 설정하지 않았습니다.

threads = workers 변경하면 모든 것이 제대로 작동하기 시작했습니다. 만일의 경우를 대비하여 이것이 누군가에게 도움이 된다면.

이것이 지금의 모습이다.

def run(host='0.0.0.0', port=8080, workers=1 + (multiprocessing.cpu_count() * 2)):
    """Run the app with Gunicorn."""

    if app.debug:
        app.run(host, int(port), use_reloader=False)
    else:
        gunicorn = WSGIApplication()
        gunicorn.load_wsgiapp = lambda: app
        gunicorn.cfg.set('bind', '%s:%s' % (host, port))
        gunicorn.cfg.set('workers', workers)
        gunicorn.cfg.set('threads', workers)
        gunicorn.cfg.set('pidfile', None)
        gunicorn.cfg.set('worker_class', 'sync')
        gunicorn.cfg.set('keepalive', 10)
        gunicorn.cfg.set('accesslog', '-')
        gunicorn.cfg.set('errorlog', '-')
        gunicorn.cfg.set('reload', True)
        gunicorn.chdir()
        gunicorn.run()

gunicorn 문서에 따르면 둘 이상의 스레드가 언급되면 작업자 클래스를 sync에서 gthread로 변경합니다.
추신:-
동기화 작업자 유형을 사용하려고 하고 스레드 설정을 1 이상으로 설정하면 gthread 작업자 유형이 대신 사용됩니다.

내 경우:

환경: Ubuntu18.04+ gunicorn+ nginx +flask

내 가상 환경에 pip install gunicorn[gevent]

gunicorn -b localhost:8000 -w 4 web:app 을 gunicorn -b localhost:8000 -k gevent web:app

효과가있다.

서로의 문제를 해결하는 데 많은 도움을 주신 모든 분들께 감사드립니다. 적절하다고 생각되는 경우 이 문제에 계속 게시하십시오.

그러나 여기 Gunicorn에 버그가 있다고 생각하지 않고 취해야 할 조치가 없다고 생각하기 때문에 이 문제를 닫습니다. 어떻게든 이에 대한 문서를 추가하거나 개선하려는 PR을 검토하는 데 기꺼이 도움을 드리겠습니다. 로그 메시지.

제 의도를 오해하지 말아주세요. Gunicorn의 버그가 의심되고 계속 논의하고 싶다면 그렇게 하십시오. 문제를 재현하는 예제 애플리케이션으로 새 티켓을 여는 것이 좋습니다. 그러나 이 시점에서 이 문제에는 너무 많은 다른 문제, 해결 방법 및 대화가 있어 매우 읽기 쉽습니다.

버퍼링 역방향 프록시 없이 Gunicorn을 실행하면 여러 가지 이유로 기본 동기화 작업자로 시간 초과가 _발생_합니다. 일반적인 것은 다음과 같습니다.

• 느린 클라이언트
• 브라우저와 프록시에 의해 열려 있는 연결 미리 연결/프리페치
• 외부 API를 호출하거나 CPU를 많이 사용하는 작업으로 인한 긴 응답

비동기 또는 스레드 작업자 유형으로 전환하거나 Gunicorn을 버퍼링 역방향 프록시 뒤에 배치할 수 있습니다. 시간 초과가 외부 API에 대한 느린 호출을 수행하거나 예상대로 중요한 작업을 수행하는 자체 코드로 인한 것임을 알고 있다면 --timeout 옵션을 늘릴 수 있습니다.

이것은 최소한 두 명의 작업자가 필요하다는 것을 의미합니다. 그렇지 않으면 서버가 교착 상태에 빠질 것입니다. 요청은 서버가 두 번째 요청(대기열에 추가됨)에 응답할 때까지 기다립니다. 작업자당 하나의 동시 요청을 받습니다.
…
2020년 1월 6일 월요일, 02:45 alpinechicken, @ . * > 썼다: 네, 한 라우트가 다른 라우트를 호출합니다 - 그게 나쁜가요?

라우트의 반환값으로 '리디렉트' 함수를 호출하는 경우가 여기에 해당합니까?

라우트의 반환값으로 '리디렉트' 함수를 호출하는 경우가 여기에 해당합니까?

아니요. 플라스크 리디렉션은 HTTP 리디렉션으로 응답하고 작업자는 새 요청을 자유롭게 수락할 수 있습니다. 클라이언트는 이 응답을 보고 작업자가 준비될 때마다 이 요청을 수신할 때 또 다른 요청을 합니다.

gnuicorn에 작업자를 추가하여 이 문제를 해결했습니다.

web: gunicorn --workers=3 BlocAPI:app --log-file -

이유를 모르겠어.

이것은 workers=1 + (multiprocessing.cpu_count() * 2) .. 를 설정한 @anilpai 주석과 관련이 있습니까?

나는 이것과 비슷한 문제가 있었다. 응용 프로그램 진입점에 오류가 있는 것으로 나타났습니다. 디버깅에서 나는 본질적으로 gunicorn에서 플라스크 앱을 시작하는 것 같았습니다. 그 후 작업자는 30초마다 시간 초과되는 무한 연결 루프에 들어갔습니다.

이것이 위의 모든 사용자에게 영향을 미치지는 않지만 일부 사용자에게는 영향을 미칠 수 있습니다.

gunicorn module.wsgi 실행 중인 module/wsgi.py 파일에서 -

application = my_create_app_function()
application.run(host="0.0.0.0")

내가 했어야 하는 반면에 -

application = my_create_app_function()
if __name__ == "__main__":
     application.run(host="0.0.0.0")

기본적으로 gunicorn을 사용할 때 application.run() 를 호출하고 싶지 않습니다. gunicorn 아래의 __name__ 는 "__main__" 가 아니지만 Flask에 있으므로 로컬에서 디버그할 수 있습니다.

gunicorn 문서에서 이에 대한 참조를 찾을 수 없지만 일반적인 오류 사례라고 생각할 수 있으므로 경고가 필요할 수 있습니다.

이것은 여전히 ​​발생하고 있습니다. Gunicorn 호출에 --preload 를 추가하면 문제가 해결되었습니다.

이 버그가 아직 수정되지 않았나요? 나는 이 정확한 행동을 관찰하고 있다.

Gunicorn은 systemd에서 다음과 같이 시작합니다.

[Service]
PIDFile = /run/gunicorn.pid
WorkingDirectory = /home/pi/pyTest
ExecStart=/usr/local/bin/gunicorn  app:app  -b 0.0.0.0:80 --pid /run/gunicorn.pid
RuntimeDirectory=/home/pi/pyTest
Restart=always
KillSignal=SIGQUIT
Type=notify
StandardError=syslog
NotifyAccess=all
User=root
Group=root
ExecReload = /bin/kill -s HUP $MAINPID
ExecStop = /bin/kill -s TERM $MAINPID
ExecStopPost = /bin/rm -rf /run/gunicorn
PrivateTmp = true

작업자 프로세스가 지속적으로 시간 초과되고 다시 시작됩니다.

Jul 10 15:19:20 raspberryVM gunicorn[10941]: [2020-07-10 15:19:20 -0700] [10941] [CRITICAL] WORKER TIMEOUT (pid:10944)
Jul 10 15:19:20 raspberryVM gunicorn[10941]: [2020-07-10 15:19:20 -0700] [10944] [INFO] Worker exiting (pid: 10944)
Jul 10 15:20:15 raspberryVM gunicorn[10941]: [2020-07-10 15:20:15 -0700] [10985] [INFO] Booting worker with pid: 10985

app.py는 사소한 Flask 앱입니다.

이 문제는 Don't Fix로 종료되었습니까?

나는 또한 같은 문제가 있었다

그러나 디버깅 후 Im은 gunicorn이 Django App을 시작하는 동안 종속성 중 하나가 예상 시간보다 오래 걸린다는 것을 알 수 있었습니다(제 경우에는 외부 DB 연결). 이로 인해 gunicron 작업자가 시간 초과되었습니다

연결 문제를 해결하면 시간 초과 문제도 해결되었습니다 ...

이것은 나의 경우가 아닐 것이다. 종속성 없이 "Hello, World" 유형의 앱으로 테스트했습니다. 그래서 나는 여전히 이것에 대해 의아해하지만 오래 실행되는 스레드로 Gunicorn을 갖는 것은 불가능한 것 같습니다. 작업자 프로세스가 다시 시작되어 장기 실행 스레드를 종료합니다.

@leonbrag
이것은 gunicorn 버그가 아닐 가능성이 높습니다. 스레드에서 위의 내 의견을 참조하십시오. 브라우저가 빈 "예상" TCP 연결을 보내고 빈 TCP 연결로부터 보호하지 않고 몇 개의 동기화 작업자로 gunicorn을 실행하는 부작용입니다.

긴(영구) 작업자 스레드로 Gunicorn 플라스크 앱을 설정하는 적절한 방법을 보여주는 참조 아키텍처/디자인이 있습니까?

이것이 버그가 아닌 경우 Gunicorn 아키텍처/디자인의 아티팩트 또는 제한으로 보입니다.

동기화 작업자가 영원히 실행되지 않고 클라이언트 연결을 수락하지 않는 이유는 무엇입니까? 이러한 작업자는 필요에 따라 소켓을 닫지만 종료 없이 계속 실행됩니다(따라서 작업자 스레드는 계속 실행됨).

@leonbrag
해결하려는 문제에 대해 더 구체적이어야 합니다.

이 스레드에서 논의된 문제는 개발 환경에서 발생하며 가장 쉬운 해결책은 동기화 작업자를 더 추가하거나 스레드 작업자를 사용하는 것입니다.

프로덕션 설정에서 이 문제를 피하려면 gevent 작업자를 사용하거나 nginx를 gunicorn 앞에 배치할 수 있습니다.
일부 PaaS는 이미 nginx를 도커 컨테이너 앞에 배치하므로 걱정할 필요가 없습니다. 다시 한 번, 솔루션은 컨텍스트와 세부 사항에 따라 다릅니다.

이것은 좋은 독서입니다.
https://www.brianstorti.com/the-role-of-a-reverse-proxy-to-protect-your-application-against-slow-clients/

문서에서 디자인 페이지를 확인할 수 있습니다. 비동기 작업자는 하나입니다.
긴 작업을 실행하는 방법.

2020년 8월 8일 토요일 18:00 leonbrag [email protected]에서 다음과 같이 작성했습니다.

적절한 설정 방법을 보여주는 참조 아키텍처/디자인이 있습니까?
긴(영구) 작업자 스레드가 있는 Gunicorn 플라스크 앱?

이것이 버그가 아니라면, 그것은 아티팩트 또는 제한 사항으로 보입니다.
Gunicorn 아키텍처/디자인.

동기화 작업자가 영원히 실행되지 않고 클라이언트 연결을 수락하지 않는 이유는 무엇입니까? 그런
작업자는 필요에 따라 소켓을 닫지만 종료하지 않고 계속 실행합니다.
(따라서 작업자 스레드는 계속 실행됩니다).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/1801#issuecomment-670944797 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAADRIWRQGIP3R5PMVJ5ENTR7VZA3ANCNFSM4FDLD5PA
.

>

내 모바일에서 보낸

웹: gunicorn --workers=3 app:app --timeout 200 --log-file-

--timeout을 증가시켜 문제를 해결했습니다.

Docker 관련 tmpfs 문제는 #1388도 참조하세요.

오, Randall에게 감사합니다. Docker에서 gunicorn을 실행할 때 gunicorn 인수에 --worker-tmp-dir /dev/shm 를 추가하는 것을 잊었습니다.

BTW는 gunicorn 캐시에 64Mb로 충분합니까?

gunicorn 앱:앱 --timeout 1000
또는
gunicorn 앱:app --preload

나를 위해 일했습니다 ... 나는 시간 초과를 선호합니다.

이상하게도 --worker-tmp-dir /dev/shm 했지만 여전히 다음을 수신하고 있습니다.

[2020-11-27 21:01:42 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:17)

/dev/shm 가 ramfs인지 확인하기 위해 벤치마킹했습니다.

매개변수는 다음과 같습니다.

    command: /bin/bash -c "cd /code/ && pipenv run gunicorn --worker-tmp-dir /dev/shm conf.wsgi:application --bind 0.0.0.0:8022 --workers 5 --worker-connections=1000"

추신: 저는 PyPy를 사용하고 있습니다.

@attajutt 시간 제한은 훌륭하지만 gunicorn 마스터 프로세스가 1000초 후에만 작업자 프로세스에서 중단을 감지하고 많은 요청을 놓칠 위험이 있습니다. 또한 여러 작업자 중 하나만 끊으면 감지하기 어려울 것입니다. 적어도 1000은 하지 않겠습니다.

@ivictbor lmk에 감사드립니다. 1000은 참고용입니다. 그럼에도 불구하고 일단 로드되면 앱이 롤링됩니다. 완벽하게 잘 실행되고 있습니다.

이 오류 문제도 있었고 여러 번 후에 문제가 발생한 것으로 나타났습니다.

1. 엔진엑스 구성
2. 구니콘/우쉬기

GAE와 같은 클라우드에 앱을 배포하면 힌트 오류가 표시되지 않습니다.
이 사례 솔루션을 사용하여 오류를 표면화하려고 시도할 수 있습니다. https://stackoverflow.com/questions/38012797/google-app-engine-502-bad-gateway-with-nodejs

502 잘못된 게이트웨이가 발생한 경우
아마도 2가지 가능성이 있을 것입니다:

1. gunicorn이 실행되지 않습니다
2. gunicorn이 시간 초과되었습니다

여기에 설명된 완전한 sulution: https://www.datadoghq.com/blog/nginx-502-bad-gateway-errors-gunicorn/

[CRITICAL] WORKER TIMEOUT 오류가 발생한 사람을 수정할 수 있기를 바랍니다.

이 스레드를 찾는 사람들에게 또 다른 가능성을 추가하는 중...

이것은 또한 도커가 웹 애플리케이션에 대해 너무 낮은 리소스 제약을 부과했기 때문에 발생할 수 있습니다. 예를 들어 다음과 같은 제약 조건이 있었습니다.

services:
  web_app:
    image: blah-blah
    deploy:
      resources:
        limits:
          cpus: "0.25"
          memory: 128M

gunicorn 대해 너무 낮았기 때문에 제약 조건을 제거할 때까지 계속 [CRITICAL] WORKER TIMEOUT 오류가 발생했습니다.

gunicorn의 경우 이 리소스는 완벽합니다. 그러나 당신은 정말로 할 필요가 있습니다
작업자 수와 귀하의 작업에 필요한 리소스에 대한 평면
애플리케이션. 128M 및 0.25cpu는 웹 응용 프로그램에 대해 정말 낮은 것처럼 보입니다.
Python으로 작성되었습니다. 일반적으로 최소한 1개의 코어 /vcpu가 필요하고
최소 512MB의 RAM.

2021년 3월 26일 금요일 02:14, Colton Hicks @ . * > 쓴:

이 스레드를 찾는 사람들에게 또 다른 가능성을 추가하는 중...

이것은 도커가 다음과 같은 리소스 제약을 부과함으로써 발생할 수도 있습니다.
웹 응용 프로그램에 대해 너무 낮습니다. 예를 들어 나는 다음을 가지고 있었다
제약:

서비스:
web_app:
이미지: ㅋㅋㅋㅋ
배포:
자원:
제한:
CPU: "0.25"
메모리: 128M

그리고 이것들은 분명히 gunicorn에 대해 너무 낮았으므로 나는 지속적으로 [CRITICAL]을 얻었습니다.
제약 조건을 제거할 때까지 WORKER TIMEOUT 오류가 발생했습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/1801#issuecomment-807855647 ,
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAADRITPZB7BMA6QW7LFNVLTFPNV3ANCNFSM4FDLD5PA
.

>

내 모바일에서 보낸

--timeout=1000이 저에게 일했습니다. 문제는 CPU 리소스가 낮은 GCP 머신이었습니다. 기본 시간 초과로 로컬 컴퓨터에서 제대로 작동했습니다.