<p>gunicorn 크리티컬 작업자 시간 초과</p>

작업자가 시간 초과되면 중재자에게 제 시간에 살아 있음을 알리지 않았음을 의미합니다. 제한 시간보다 오래 걸릴 수 있는 요청 중에 실행된 작업이 있습니까?

@jseidou 범프.

@benoitc님 답변이 늦어 죄송합니다. 내가보고있는 문제는 실제로이 작업을 수행하는 비활성 스레드입니다. 내 활성 스레드는 시간 초과되지 않으며 부하가 적은 비활성 스레드는 정상적으로 시간 초과되는 것보다 더 심각한 시간 초과 오류를 제공합니다. gevent에서 토네이도로 전환했는데 중단 문제가 해결된 것 같지만 여전히 30초마다 임계 시간 초과를 지속적으로 제공하는 3명의 작업자가 있습니다. 정상적인 시간 초과인 경우 심각한 오류가 아니어야 합니다.

나는 똑같은 문제에 직면하고 있습니다.
거니콘 19.7.1
제벤트 1.2.1
파이썬 3.5.3
Docker에서 실행, 공식 " python:3.5 "를 기반으로 하는 이미지

@jseidou 중재자가 이에 반응한다는 점에서

아마도 당신의 작업자 중 한 명이 gunicorn 작업자가 중재자에게 알리지 못하도록 차단 작업을 수행하고 있을 것입니다. 긴 작업이 있는 경우 잠자기 등으로 geven 스케줄러를 수시로 트리거해야 합니다. 또는 토네이도 스케줄러를 다시 호출하는 모든 것.

문제를 재현하려면 어떻게 해야 합니까?

@saabeilin 동일 ^^

동일한 내용이 표시됩니다. 요청을 제공하지 않는 경우에도 작업자가 시간 초과됩니다. 내가 한 일은 AWS ECS에서 내 컨테이너를 시작하는 것뿐입니다.

[2017-06-27 20:41:56 +0000] [1] [DEBUG] Current configuration:
proxy_protocol: False
worker_connections: 1000
statsd_host: None
max_requests_jitter: 0
post_fork: <function post_fork at 0x7f6bbc3f1938>
errorlog: -
enable_stdio_inheritance: False
worker_class: sync
ssl_version: 2
suppress_ragged_eofs: True
syslog: False
syslog_facility: user
when_ready: <function when_ready at 0x7f6bbc3f1668>
pre_fork: <function pre_fork at 0x7f6bbc3f17d0>
cert_reqs: 0
preload_app: False
keepalive: 2
accesslog: -
group: 0
graceful_timeout: 30
do_handshake_on_connect: False
spew: False
workers: 4
proc_name: None
sendfile: None
pidfile: None
umask: 0
on_reload: <function on_reload at 0x7f6bbc3f1500>
pre_exec: <function pre_exec at 0x7f6bbc3f1ed8>
worker_tmp_dir: None
limit_request_fields: 100
pythonpath: None
on_exit: <function on_exit at 0x7f6bbc3f7758>
config: None
logconfig: None
check_config: False
statsd_prefix:
secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
reload_engine: auto
proxy_allow_ips: ['127.0.0.1']
pre_request: <function pre_request at 0x7f6bbc3f70c8>
post_request: <function post_request at 0x7f6bbc3f71b8>
forwarded_allow_ips: ['127.0.0.1']
worker_int: <function worker_int at 0x7f6bbc3f1c08>
raw_paste_global_conf: []
threads: 1
max_requests: 0
chdir: /opt/app
daemon: False
user: 0
limit_request_line: 4094
access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
certfile: None
on_starting: <function on_starting at 0x7f6bbc3f1398>
post_worker_init: <function post_worker_init at 0x7f6bbc3f1aa0>
child_exit: <function child_exit at 0x7f6bbc3f7320>
worker_exit: <function worker_exit at 0x7f6bbc3f7488>
paste: None
default_proc_name: app:app
syslog_addr: udp://localhost:514
syslog_prefix: None
ciphers: TLSv1
worker_abort: <function worker_abort at 0x7f6bbc3f1d70>
loglevel: DEBUG
bind: ['0.0.0.0:5005']
raw_env: []
initgroups: False
capture_output: False
reload: False
limit_request_field_size: 8190
nworkers_changed: <function nworkers_changed at 0x7f6bbc3f75f0>
timeout: 30
keyfile: None
ca_certs: None
tmp_upload_dir: None
backlog: 2048
logger_class: gunicorn.glogging.Logger
[2017-06-27 20:41:56 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-06-27 20:41:56 +0000] [1] [DEBUG] Arbiter booted
[2017-06-27 20:41:56 +0000] [1] [INFO] Listening at: http://0.0.0.0:5005 (1)
[2017-06-27 20:41:56 +0000] [1] [INFO] Using worker: sync
[2017-06-27 20:41:56 +0000] [8] [INFO] Booting worker with pid: 8
[2017-06-27 20:41:57 +0000] [9] [INFO] Booting worker with pid: 9
[2017-06-27 20:41:57 +0000] [10] [INFO] Booting worker with pid: 10
[2017-06-27 20:41:57 +0000] [12] [INFO] Booting worker with pid: 12
[2017-06-27 20:41:57 +0000] [1] [DEBUG] 4 workers
[2017-06-27 20:42:15 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:15 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-06-27 20:42:46 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-06-27 20:42:46 +0000] [12] [INFO] Worker exiting (pid: 12)
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 3 workers
[2017-06-27 20:42:46 +0000] [24] [INFO] Booting worker with pid: 24
[2017-06-27 20:42:46 +0000] [25] [INFO] Booting worker with pid: 25
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 4 workers

로컬에서 실행할 때는 발생하지 않습니다. :-/

gevent 작업자로 전환하면 해결된 것 같습니다. ¯\_(ツ)_/¯

#1194의 복제품인 것 같아요.

나는 최근에 이런 일이 반복적으로 일어나는 것을 보았고 나에게 그것은 노트북을 잠자기 상태로 만드는 것과 관련이 있는 것 같습니다. 뚜껑을 열면 이런 메시지가 잔뜩 뜬다. 이것이 도움이 될지 확신할 수 없지만, 나는 그것을 언급할 것이라고 생각했습니다...

gunicorn --daemon --workers 2 --timeout 120 --bind 127.0.0.1:4000 --pid /var/run/mshc_admin.pid --user danilovskoe --group danilovskoe --chdir /home/danilovskoe/mshc2/src /flask/ --env MSHC_PRODUCTION=/etc/monit/mshc.config.py admin_ gunicorn:app

타임아웃 30초
요청 받기

우분투 16.04
플라스크 0.12.2
Python 3.6.3(기본값, 2017년 10월 4일, 02:55:45)
[GCC 5.4.0 20160609] 리눅스에서
gunicorn(버전 19.7.1)

고민을 만났습니다.

앱을 시작한 직후에 작동합니다. 그러나 요청이 있는 경우에만 [CRITICAL] WORKER TIMEOUT 가 트리거됩니다. 예를 들어,

[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: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: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. 

CentOS: 6.7
Python: 3.6.3
Gevent: 1.2.2
Greenlet: 0.4.9
Gunicorn: 19.7.1

RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

작업자 클래스를 eventlet 로 전환했을 때, 즉,
gunicorn --worker-class eventlet --log-level debug --bind 0.0.0.0:8080 app ,
괜찮아.

알림: 내 앱은 가상 호스트나 클라우드 호스트가 아닌 물리적 호스트에서 실행됩니다.

업데이트:

그래서 나는 그것이 gevent 또는 gevent 작업자의 문제라고 생각합니다.

gevent가 문제를 해결하고 gevent가 문제를 일으키는 이 문제에 대한 보고가 있습니다. 여기서 근본 원인을 식별할 수 없습니다. 일부 보고서는 #1194와 같을 수 있지만 다른 보고서는 그렇지 않을 수 있습니다.

누구든지 재현할 수 있는 최소한의 사례를 공유할 수 있다면 도움이 될 것입니다.

확실히 동일한 문제인지 확실하지 않지만 다음 설정으로 Virtualbox를 사용하여 100% 재현할 수 있습니다.

호스트: 윈도우 10
게스트: 우분투 16.04
유니콘: 19.7.1

기본 NAT 연결을 통해 호스트와 게스트 간에 TCP:8000을 전달합니다. sync 작업자를 사용하여 호스트 에서 localhost:8000 에 대한 모든 요청은 이러한 오류를 로그에 표시하지만 내가 guest 에 대해 동일한 요청을 하면 로그가 지워집니다. --worker-class eventlet 전환하면 추적이 제거됩니다.

Virtualbox가 완전히 다른 차원이라는 점에 감사하지만 위에서 설명한 것과 매우 유사하게 들리고 일관되게 재현할 수 있습니다(적어도 저에게는).

느린 업로드에서 이런 일이 발생하는 것을 보고 있습니다. 업로드하는 동안(Django 사이트로) 작업자 시간 초과에 도달하면 업로드가 중단됩니다.

@lordmauve 예상되는 동기화 작업자를 사용하는 경우. 긴 요청은 작업자를 차단하고 결국 중재자는 작업자를 종료합니다. 긴 요청이 성공할 것으로 예상되는 경우 다른 작업자 유형을 사용할 수 있습니다.

이 스레드를 읽는 사람은 재생산을 위해 최소한의 케이스로 다시 여십시오. 여기에서 수행할 깨끗한 조사를 볼 수 없습니다. AWS/ECS의 경우 나열된 구성을 테스트할 수 있을 때까지 #1194를 열어 둡니다(https://github.com/benoitc/gunicorn/issues/1194#issuecomment-371250650).

여전히 이 문제가 있는 사람은 시간 초과를 늘리고 작업자 클래스 유형을 변경하는 것 외에도 응용 프로그램의 리소스 가용성을 확인하십시오.

Docker Swarm을 사용하여 애플리케이션을 배포하려고 할 때 이 문제가 발생했고 애플리케이션에 대해 리소스를 너무 낮게 제한하고 있음을 깨달았습니다. 리소스를 늘리면 문제가 해결됩니다.

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

이것은 버그가 아니라 우리가 앱을 구성하는 방식이라고 생각합니다.

@jseidou 중재자가 이에 반응한다는 점에서

아마도 당신의 작업자 중 한 명이 gunicorn 작업자가 중재자에게 알리지 못하도록 차단 작업을 수행하고 있을 것입니다. 긴 작업이 있는 경우 잠자기 등으로 geven 스케줄러를 수시로 트리거해야 합니다. 또는 토네이도 스케줄러를 다시 호출하는 모든 것.

문제를 재현하려면 어떻게 해야 합니까?

@saabeilin 동일 ^^

감사합니다.
나에게 이것은 이전에 클라우드 저장소에서 다운로드한 큰 파일을 제공할 때 발생합니다.
요청 시 파일이 클라우드 스토리지에서 로컬 디스크로 검색된 다음 클라이언트로 스트림 암호 해독됩니다. 클라우드 저장소에서 다운로드하면 10분 이상 걸리더라도 제대로 작동합니다.
작업자가 디스크에서 클라이언트로 파일을 스트림 해독하기 시작하면 이 차단 작업으로 인해 시간이 초과되기 때문에 수백 MB 후에 종료됩니다.