Gunicorn: Gunicorn 동기화 작업자가 docker + AWS에서 시간 초과됨

hrmmm 위의 로그에서 시간이 절대 변하지 않는다는 것을 알 수 있습니다. 내가 확인합니다

감사합니다. 감사합니다!

이 버그의 영향을 받을 수 있습니다.

AWS(Elastic Beanstalk + EC2 Container Service)의 Docker 이미지 내에서 gunicorn을 실행하고 있습니다.
초기화 직후와 AWS에서 Docker 이미지를 실행할 때만 발생하기 시작하는 지속적인 작업자 시간 초과가 있습니다.
동일한 HTTP 요청은 때로는 몇 ms, 때로는 20-30초가 걸립니다. 존재하지 않는 페이지, 인증되지 않은 단순한 "Hello world" 문자열 페이지 또는 데이터베이스에서 레코드를 가져오는 페이지인지는 중요하지 않습니다.

추가 세부정보 :

• Gunicorn 버전 : 19.5.0 및 19.6.0.
• 기본 Docker 이미지 : python:3.4 ( OS : Debian Jessie )
• Docker 버전 : 1.9.1(Amazon ECS에서 관리), OS : Amazon Linux AMI 2016.03(Amazon EB에서 관리).
• 웹 애플리케이션 프레임워크 : Django 버전 1.9.6 및 1.9.7.

영향을 받지 _않은_

• 로컬 머신 , _inside_ 및 _outside_ 모두 Docker 컨테이너입니다. OS : 우분투 16.04 LTS, 도커 : 1.11.2.
• 헤로쿠 ( OS : 우분투 14.04 LTS)

Amazon 컨테이너 로그 :

[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)
(...)

`

감사 해요.

저도 이거 보고 있습니다. 내 의심은 Elastic Load Balancer입니다. 이전 회사에서 paste 를 사용했는데 이로 인해 ELB에 문제가 발생했습니다. 어떻게 든 연결을 재사용하고 paste 에서 딸꾹질을 일으키고 있다고 생각합니다.

저는 이제 gunicorn을 사용하는 새 직장에 있으며 ELB 뒤에 서버를 배치하기 시작할 때까지 모든 것이 괜찮았습니다.

대신 gevent 작업자를 사용하여 문제를 해결했습니다.

그렇다면 이것이 연결을 유지하고 동기화 작업자를 묶는 ELB의 문제입니까? 우리가 의도적으로 동기화 작업자와의 연결을 닫아야 한다고 신호를 보내기 때문에 매우 이상하게 느껴질 것입니다. https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L168

하지만 의도적으로 연결을 닫을 수 있습니다. client.close() 호출을 무조건적으로 이동하는 테스트를 원하는 사람이 있다면 흥미로운 테스트가 될 수 있습니다. https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L199

ELB의 유휴 시간 초과가 작업자 시간 초과보다 낮은지 확인할 수도 있습니다. 이것이 문제의 원인인지도 신속하게 확인할 수 있습니다. http://docs.aws.amazon.com/elasticloadbalancing/latest/ 클래식/config-idle-timeout.html

@tilgovi elb는 현재 최선의 추측입니다. a) gunicorn이 ELB 뒤에 있고 b) gevent 작업자를 사용하여 문제가 수정된 경우에만 발생하기 때문입니다. 근데 또 누가알아..

ELB 뒤에서만 발생하며 프로토콜 HTTP 또는 HTTPS가 ELB에 설정된 경우에만 발생합니다.
프로토콜을 TCP 또는 SSL로 변경하면 문제가 사라집니다.
아직 동기화 작업자를 사용하여 문제를 해결하는 방법을 아는 사람이 있습니까? 액세스 로그를 모니터링하고 ELB의 HTTP/HTTPS에 대해서만 활성화된 X-Forwarded-For 헤더를 볼 때 지금까지 설명한 수정 사항(HTTP 대신 TCP)을 사용했습니다. :)

이상하게도, 우리가 같은 페이지에 있는지 확인하기 위해 ELB에서 HTTP/HTTPS 옵션을 사용할 때 일종의 최적화가 있다는 의미입니까? 이 최적화로 인해 동기화 작업자에 문제가 발생합니까?

@ecs HTTP/HTTPS 로드 밸런서가 동일한 TCP 연결을 재사용하는 경우 ELB가 오랫동안

Btw, 영향을 줄 수 있는 많은 요인(gunicorn 버전, 작업자 클래스, 내부 도커 여부, ELB 프로토콜)이 있으므로 누군가 ELB의 TCP 프로토콜이 HTTP와 달리 작동하는지 테스트하고 확인하면 좋을 것입니다. Ubuntu 14.04 및 gunicorn 버전 19.3.0에서 호스팅되는 도커에서 테스트 중입니다.

나도 같은 문제를 안고있어:
[2016-10-03 12:13:17 +0000] [6] [CRITICAL] 작업자 시간 초과(pid:16)
[2016-10-03 12:13:17 +0000] [16] [INFO] 작업자 종료 (pid: 16)
[2016-10-03 12:13:17 +0000] [6] [CRITICAL] 작업자 시간 초과(pid:20)
[2016-10-03 12:13:17 +0000] [20] [INFO] 작업자 종료 (pid: 20)
[2016-10-03 12:13:17 +0000] [33] [INFO] pid로 작업자 부팅: 33

내 설정.

kube-aws를 사용하여 AWS에서 core-os가 있는 kubernetes 클러스터를 설정하고 있습니다. https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws

나는 gunicorn 및 동기화 작업자를 사용하는 파이썬 앱이 있습니다. 이들을 위한 서비스는 내 사이트 인증서와 함께 HTTPS 로드 밸런서를 사용합니다. 모든 작업자는 기본 시간 초과 시간인 30초 이후에 시간 초과된 것으로 간주됩니다. 결국 모두 다시 시작됩니다. Kubernetes는 컨테이너가 종료될 때 결국 컨테이너를 다시 시작합니다. 이러한 다시 시작은 지속적으로 발생합니다. 위의 누군가가 gevent가 문제를 해결한다고 언급했지만 시도해 볼 수는 있지만 왜 이런 일이 발생하는지 이해하고 싶습니다.

우리는 현재 이 문제를 보고 있습니다. 기회가 있을 때 더 자세한 내용을 게시하도록 노력하겠습니다. gevent로 이동하면 실제로 문제가 해결되므로 동기화 작업자와 관련이 있습니다. 이것은 ECS 및 ELB가 있는 AWS에 있습니다.

우리 앱 중 하나에서도 동일한 이상한 문제가 발생했습니다. 리스너를 HTTP에서 tcp로 변경하면 실제로 문제가 해결됩니다.

누구든지 문제를 재현하는 단계별 방법을 제공할 수 있습니까? (구성 단계 등) 또는 최소한 해당 환경을 설정하는 간단한 방법을 알려주세요. 이번 주에 살펴보겠습니다.

이러한 밸런서에 대해 HTTP에 의존하려면 일반적으로 연결 유지(tcp 제외)를 처리해야 하므로 동기화 작업자가 지원을 위해 업데이트될 때까지 동기화 작업자를 사용하는 모든 것이 문제가 될 수 있습니다.

어쨌든 알려주십시오.

기본 Flask 앱을 ​​설정하고 HTTP 로드 밸런싱 및 위의 구성을 사용하여 AWS의 docker 내부에서 동기화 작업자와 함께 gunicorn으로 실행하기만 하면 됩니다.

AWS의 Ubuntu 14.04 LTS에서 실행되는 도커 이미지 내에서 gunicorn 19.4.5를 사용하면 >1 동기화 작업자와 기본 30초 제한 시간으로 실행할 때 작업자 제한 시간이 계속 표시됩니다.

애플리케이션에 요청할 필요가 없으며 로그를 모니터링하기만 하면 작업자가 시간 초과되는 것을 볼 수 있습니다.

• 이 동작과 이를 재현하기 위한 기본 접근 방식을 확인할 수 있습니다.
  
  
  
  • 동작은 Docker에 국한되지 않고 동기화 작업자/keepalive 설정에 국한되므로 제목 변경을 고려할 수 있습니다...
  
  
• 여기에 설명된 내용을 따르도록 keepalive 설정을 수정했습니다. https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ (가장 흥미로운 부분은 인용문입니다. AWS ELB 설명서에서) 서버가 더 이상 이 동작을 나타내지 않는 것으로 나타났습니다.
• 또한 추가로 gthread 작업자 클래스로 변경했으며 결과가 지금까지 매우 수용 가능하다는 것을 알았습니다.

현재 65초 제한 시간(AWS ELB 제한 시간은 60초, AFAIK)으로 gevent 작업자를 사용하고 있습니다. 한 번에 1개의 요청이 전송되는 한 클라이언트만 요청을 하는 경우에도 여전히 504 오류가 발생하는 경우가 있지만 아직까지는 이유를 밝힐 수 없었습니다.

@obi1kenobi ELB 시간 초과 옵션 이상으로 keepalive를

@lenucksi keepalive는 이미 ELB 제한 시간보다 5초 더 높습니다. 서버의 시계가 그렇게 많이 구동되지 않기를 바랍니다. :)

저도 ELB 뒤의 EC2 인스턴스의 Docker 컨테이너 내에서 gunicorn 19.6을 실행하는 이 문제에 직면했습니다(EC2 인스턴스에 대한 역방향 프록시를 위한 기본 HTTP 프로토콜 사용).

앞서 제안한 대로 작업자 클래스를 gevent로 설정하면 이 문제가 해결되었습니다(이전에는 기본 sync 작업자 클래스를 사용했음).

나는 문제를 재현하기 위한 최소한의 예를 시도하고 문서화할 것입니다.

다른 사람들의 말을 뒷받침하기 위해 ELB는 EC2 인스턴스에 대한 연결을 열고 추가 요청을 처리하지 못하도록 gunicorn을 잠그는 방식으로 열려 있는 것으로 보입니다.

Gunicorn이 ELB의 요청 시간을 초과하여 연결이 보류되어 종료되면 그 뒤에 대기 중인 모든 보류 중인 요청도 실패합니다(ELB의 상태 확인을 포함하여 인스턴스가 ELB에서 제거되어 디버그하기가 더 어렵습니다. ) ).

이 증상은 Docker와 관련이 없는 이 이전 문제에서 관찰된 것과 중복됨을 나타냅니다. https://github.com/benoitc/gunicorn/issues/588

@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 를 사용하려고 시도했지만 전혀 도움이 되지 않았습니다. 사실 놀랍게도 보기가 더 나빠졌습니다. 5명의 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 간의 상호 작용에 대한 새로운 통찰력을 불러일으킬 경우를 대비하여 보고할 것이라고 생각했습니다.

비슷한 설정(ELB->ECS Docker Container->Gunicorn->Django를 실행하는 convox)이 있으며 다음 구성 변경이 도움이 된 것 같습니다.

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

ELB 유휴 시간 제한을 60초로 설정했습니다.

이 설정을 변경하기 전에 연결 유지, 시간 초과 및 동기화 작업자에 대한 기본값을 사용했습니다.

흥미롭게도 이 문제는 UTC 4월 10일 오전 4시에 표시되기 시작했습니다. 앱은 지난 목요일 이후 아무런 변경 없이 정상적으로 실행되었습니다.

쌓기만 하면 도커가 없지만 베어 aws 인스턴스에는 ELB 뒤에서 동일한 문제가 발생했습니다. osx에서 NP를 작동하지만 ELB와 동일한 문제가 있는 ubuntu16이 잘렸습니다. gevent 작업자 클래스가 [나를 위해] 수정하는 것 같습니다.

이 스레드의 누군가가 이것을 확인할 수 있습니까?
https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx

@erikcw 는 이 솔루션이 작동하는 것을 찾은 것 같습니다. 이 문제를 종료하고 싶습니다. 누구든지 Gunicorn 작업자 시간 초과 및 연결 유지 시간 초과를 높인 후 이를 재현할 수 있다면 그렇게 말씀해 주십시오.

또는 ELB의 유휴 시간 초과를 낮추십시오.

야생의 클라이언트(또는 사악한 클라이언트)가 ELB처럼 행동하여 동일한 문제를 일으킬 수는 없나요?

@six8 네. ELB도 이것으로부터 당신을 보호하지 않습니다. 문서에서는 이에 대해 설명합니다. http://docs.gunicorn.org/en/latest/design.html#choosing -a-worker-type

어떤 사람들은 이 위협에 신경 쓰지 않고 ELB 에지나 뒤에 Gunicorn을 배치하기를 원합니다. 여기서 논의된 문제는 ELB 자체로 인한 작업자 시간 초과입니다. 추가 역방향 프록시 없이 동기화 작업자가 있는 ELB 뒤에서 gunicorn이 작동하도록 하는 권장 구성을 제공하고 싶습니다.

나는에 gunicorn 호출을 변경하여뿐만 아니라의 솔루션을 @erikcw 시도 :

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에서 실행되는 애플리케이션이 있습니다. 나는 아직 어떤 문제도 보지 못했다.

누구나 재현 가능한 배포를 제공할 수 있습니까?

쌓이기도 합니다. ELB와 함께 AWS에서 Kubernetes를 사용하여 이 문제를 확인했습니다. 현재 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 작업자와 함께 작업자는 중재자에게 모든 연결과 별도의 그린렛에서 활성 상태를 알려야 합니다. 연결 유지 설정은 이것에 전혀 영향을 미치지 않아야 합니다. gevent가 설계된 대로 작동하지 않는 등 애플리케이션에 문제가 있거나 이러한 다른 시나리오에서 공통적으로 발생할 수 있는 설정 문제가 있습니다.

이 스레드의 모든 사람은 이 문제를 재현하는 응용 프로그램을 제공하십시오. 나는 그것을 재현하지 못했습니다. 재현할 단계가 없으면 닫고 싶은 충동이 듭니다. 이러한 의견에는 여러 권장 사항과 매우 다른 문제가 묻혀 있을 수 있습니다. 이 문제로 무엇을 해야할지 알기 어렵습니다.

@tilgovi gevent 에 작업자 클래스를 지정하지 않을 때(예: 기본 동기화 작업자 사용) 이 문제가 발생했습니다. 내 설정은 pypy3(PyPy 5.8.0-beta0), falcon 1.2 등을 사용하는 virtualenv입니다(Falcon에 대한 이해는 pypy3에서 공식적으로 지원되지 않음). 나는 https://github.com/7ideas/cookiecutter-falcon 에서 cookiecutter를 사용하고 모든 최신 패키지로 업그레이드했으며 브라우저에서 sample_resource를 로드하려고 시도하고 httpie로 여러 번 치면 간헐적으로 작업자 충돌 오류가 표시됩니다( 예를 들어 요청이 지연되면 오류가 표시됩니다. 요청을 취소하지 않으면 결국 응답하게 됩니다. 이것은 동기화의 기본 작업자 클래스에서만 발생했습니다. gevent를 사용하도록 지정하면 모든 것이 작동했습니다.

@jhillhouse92 감사합니다

@tilgovi 시간 초과 문제가 계속 발생하고 있습니다. 내일 더 문제를 해결하고 더 정확한 정보로 업데이트를 게시하겠습니다. 이 문제를 계속 열어 두십시오. 다양한 문제가 발생할 수 있다는 것이 옳았지만 일반적인 주제는 gunicorn 작업자(아마도 sync 작업자 클래스, tbd와 함께)가 AWS/ELB를 사용하여 배포된 애플리케이션과 함께 gunicorn을 사용할 때 시간 초과 문제가 있다는 것입니다. 우리가 정확한 문제를 분리하지 않았더라도 여기에 뭔가 잘못된 것이 있습니다. 더 파고들 가치가 있습니다. 내일 업데이트 하겠습니다.

언급할 가치가 있는, 위에서 언급한 스택을 사용하여 Docker/AWS/ELB가 아닌 로컬에서 이 문제를 경험했습니다.

그래서 저는 gevent를 사용하고 액세스 로그를 캡처하고 AWS/ELB를 사용하여 앱을 배포하려고 합니다.

도커 파일 명령:

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/AWS/ELB 스택에서만 나타납니다(저를 위해).

@tilgovi 내가 처음에

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에서 실행됩니다. 도커 이미지는 공식 포스트그레스 9.6입니다.
• 앱 서버는 EC2 외부 VM의 Docker에서 실행됩니다. 도커 이미지는 공식 python 3.6입니다.
• 포트 5432/tcp만 AWS 보안 그룹에서 열립니다.

흥미롭게도 앱 서버에서 postgres 서버로 보내는 대부분의 요청은 하나를 제외하고는 괜찮았습니다. 해당 쿼리는 영원히 실행되는 것으로 보이며, 이는 gunicorn 작업자 시간을 초과합니다.

앱을 로컬에서 사용하면 문제가 사라집니다.

앱 서버를 고정화하지 않으면 문제도 사라집니다.

내 임시 수정 사항은 AWS 보안 그룹 설정을 통해 앱 서버와 postgres 서버 간의 모든 연결을 여는 것입니다. 이제 모든 것이 다시 제대로 작동합니다.

Python 컨테이너와 AWS 간에 연결 문제가 있는 것 같습니다. AWS 로그 스트림을 철저히 검토한 후 업데이트하겠습니다.

감사합니다!! ELB 및 인스턴스 프로토콜을 HTTP에서 TCP로 변경하면 잘 작동했습니다 👍

문제는 AWS에만 국한된 것이 아니라 Gunicorn과 결합할 때 Docker 자체에 국한된 것 같습니다. 적어도 프로덕션 환경에서는 gevent 에서도 이것을 볼 수 있습니다.

@tilgovi 다음은 이 오류를 재현하는 간단한 앱입니다(

app.py:

import falcon


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


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

도커 파일:

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

로그는 다음과 같습니다(적어도 Docker 17.06.2-ce-mac27(19124)를 사용하는 macOS Sierra의 경우).

[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) 나는 (분명히) 작업 정의에서 컨테이너 전용 메모리 양(128MB에서 256MB로)을 증가시켜 문제를 해결했습니다.
지금까지 더 이상 오류가 없습니다. 다시 발생하면 여기에 신고하겠습니다.

여기에 코러스를 조금 추가했지만 gevent로 전환해야만 해결할 수 있었습니다.

나는 운이없는 동기화 작업자와 시간 초과를 90으로 늘리고 연결 유지를 75로 늘리려고했습니다.

또한 흥미롭게도 이 시나리오에서 내 ELB는 HTTP가 아닌 TCP 수준 전달만 수행합니다.

좋아, 이것을 설명하는 몇 가지 참조를 찾았습니다. [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 작업자에게도 문제가 있는 것 같습니다.

@jmagnusson 귀하의 예(이 주석: https://github.com/benoitc/gunicorn/issues/1194#issuecomment-331740187)에서 동기화 작업자를 사용하는 것 같습니다.

[2017-09-23 22:31:00 +0000] [1] [정보] 작업자 사용: 동기화

@tilgovi 사실이지만 gevent 작업자에게도 이것을 경험했습니다. gevent로 재생산하는 시간을 갖도록 노력하겠습니다.

이것은 저일 수도 있지만 EC2 보안 그룹 -> 인바운드 규칙에는 단일 IP(내 IP: XX.XX.XX.XX)만 허용하는 포트 5000(여기서는 gunicorn)에 대한 사용자 지정 TCP 규칙이 있습니다. /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. 작업자 프로세스가 하나의 요청을 받은 경우에만 알림이 진행되지 않습니다. 따라서 요청이 있든 없든 마스터는 30초 후에 작업자 프로세스를 종료합니다.
2. 1차 요청이 종료되면 바로 2차 요청을 보냈는데 2차 요청이 차단되어 응답이 없습니다. 30초 시간 초과에 도달하면 작업자 프로세스가 종료되고 새 작업자 프로세스가 두 번째 요청에 응답합니다. 그런 다음 서버가 다시 중단되었습니다.
3. 작업자 프로세스가 정지되면 SIGTERM 와 같은 마스터로부터 신호를 수신하지 않습니다. Graceful timeout에 도달하면 마스터는 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 를 작업자로 사용하면 괜찮습니다.

나는 그것이 일종의 구식이라고 생각하기 때문에 이 문제를 닫을 것입니다. 내가 판단할 수 있는 한 관찰된 동작은 AWS Classic Load Balancer가 사전 개방 최적화를 수행하기 때문입니다. 이 최적화는 로드 밸런싱 작동 방식에 대한 설명서에 따라 Classic Load Balancer에서만 수행됩니다. Application Load Balancer로 전환하면 문제가 해결됩니다. 또한 이 블로그 게시물에 설명된 대로 AWS에 사전 개방 최적화를 비활성화하거나 Gunicorn에 대한 작업자 제한 시간을 늘리도록 요청할 수 있습니다.

@tilgovi FWIW 나는 이것을 ALB에서 보았습니다. 저는 클래식 로드 밸런서를 사용한 적이 없습니다.

@tilgovi 나 역시 클래식을 사용한 적이 없는 ALB 전용 환경에서 이것을 반복적으로 관찰했다. 작업자 시간 초과 조정에도 불구하고 우리는 이것을 계속 보았습니다.

@tilgovi 나는 이것을 만났다. 저는 AWS를 사용한 적이 없습니다.

누군가가 이것을 재현하고 디버깅을 시도해야 합니다. ALB로 재생산할 수 없고 AWS 외부에서 재생산하는 방법을 볼 수 없습니다.

@xgfone 자신의 문제를 열고 싶을 수도 있습니다. 이 문제의 제목은 "docker + AWS"입니다.

AWS 로드 밸런서에서 Docker 없이 이것을 경험한 사람이 있습니까? 나는 약간 혼란 스럽습니다, 나는 인정해야합니다 :)

내 인상은 문제가 실제로 Docker와 더 관련이 있다는 것입니다. 적어도 로컬 컴퓨터의 Docker 내부에서 여러 gunicorn 동기화 작업자를 실행하는 것과 정확히 동일한 문제가 있었습니다.

이 구성은 베어메탈 및 Digital Ocean에서 가상화된 Ubuntu 및 RHEL 시스템에서 Docker 없이도 잘 작동했습니다.

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

Docker 내부(RHEL, 다른 모든 항목 동일) 내에서 작업자는 항상 시간 초과에 도달했고 계속해서 영구적으로 다시 시작되었습니다. 이 스레드에서 권장 사항을 가져와 완벽하게 작동하는 다음으로 전환했습니다.

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

이것이 이 스레드와 관련이 없다고 생각되면 여기에서 제거하고 다른 곳에 두겠습니다 ;-)

베스트, 보리스

@tilgovi

이 오류는 arbiter.py, murder_workers 합니다. murder_workers 함수는 SIG_QUEUE 가 비어 있을 때 호출됩니다(예: 신호를 기다리는 동안).

그런 다음 매초 시간 초과에 도달했는지 확인합니다. 남은 시간은 gevent 작업자가 제어된 무한 루프에 있고 self.alive 가 파일을 업데이트하는 self.notify 를 호출했기 때문에 항상 1초 또는 0초였습니다. 파일에 대한 업데이트는 gunicorn이 마지막 활성 시간이 발생한 시간을 확인하는 방법입니다.

따라서 murder_workers 함수의 TTL(Time to Live) 검사가 실패하는 유일한 방법은(예: 너무 오래 유휴 상태였다고 함) gevent live 속성이 변경된 경우입니다. 다음 메서드가 이를 제어합니다.

handle_quit
handle_request (최대 요청이 수신된 경우 기본적으로 요청 수의 2^64비트 또는 32비트 OS인 경우 2^32)
changed (파일이 변경된 경우 리로더에서 호출됨)
handle_exit
handle_abort

이 메서드는 신호에서 호출됩니다.

handle_quit - SIGQUIT, SIGINT
handle_exit - SIGTERM
handle_abort - SIGABRT

따라서 내가 볼 수있는 두 가지 가능한 문제가 있습니다.

1. 알림 메서드는 루프 중에 파일을 업데이트할 수 없습니다.
2. 신호가 잘못 전송되고 있습니다.

가장 가능성 있는 원인은 2번이라고 생각합니다. 신호의 주요 소스는 중재자 파일 내에 있으며 다음 예외에 의해 트리거됩니다.

• StopIteration
• KeyboardInterrupt
• HaltServer
• Exception (처리되지 않은 예외)

StopIteration 예외가 req = six.next(parser) 의 async.py 파일에서 트리거된 범인일 가능성이 가장 높다고 생각합니다. 이 다음 메소드는 parser.next()를 호출하는 것 같습니다.

Parser.next() 는 다음 2가지 조건에서 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개의 댓글 중 여러 앱과 환경에서 볼 수 있습니다. 더 조사할 가치가 있다고 생각하고 다시 열거나 제목이 마음에 들지 않는 경우 , 작업자가 심각한 시간 초과로 새로운 글로벌 문제를 만듭니다.

이것을 다시 열고 다음 조합을 테스트해 보겠습니다.

• 도커 로컬
• Classic Load Balancer를 사용하여 AWS 도커
• Application Load Balancer로 AWS 도커

누구든지 이것을 재현할 수 있는 repo를 만들고 싶다면 도움이 될 것이지만 아마 이번 주말에 할 수 있을 것입니다.

이 문제가 있으며 AWS를 사용하고 있지 않습니다.
내 설정은 NGINX -> Docker 컨테이너(gevent 작업자가 있는 Gunicorn + 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

그러나 컨테이너에서 사용할 수 있는 메모리가 제한됩니다. 동기 작업자는 잠재적으로 무거운 여러 파이썬 인터프리터를 시작합니다. CPU 수는 사용할 도커 컨테이너를 프로비저닝한 것이 아니라 머신의 전체 CPU 수를 기반으로 합니다. 제한된 컨테이너를 실행하는 경우 대신 작업자 수를 기준으로 해야 합니다.

응용 프로그램마다 다르지만 필자의 경험에 따르면 린 구성에서는 작업자당 256메가, 안전하려면 512메가입니다.

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, 작업자당 약 40MB입니다.

어쨌든 gunicorn 19.6.0 > 19.9.0 및 gevent 1.2.2 > 1.3.6 업데이트하면 ELB 상태 확인이 다시 안정적이고 로컬에서 ~300rps가 됩니다. 나는 APM 로그인이 있을 때까지 gunicorn/gevent를 의도적으로 업데이트하지 않았습니다. 그렇게 하면 우연한 일을 촉발한 것 같습니다. gevent를 업데이트하면 당연히 가장 큰 향상을 얻을 수 있었지만 gunicorn을 업데이트하면 10% 정도 더 추가되는 것 같았습니다.

아직 변경 로그를 자세히 살펴보지 않았지만 유지 관리자가 가장 가능성 있는 원인을 밝힐 수 있습니까?

어쨌든, gunicorn 19.6.0 > 19.9.0 및 gevent 1.2.2 > 1.3.6을 업데이트하면 다시 확고한 ELB 상태 확인이 제공되고 로컬에서 ~300rps가 됩니다.... gevent 업데이트가 가장 큰 향상을 주었습니다.

와, 정말 멋지네요!

마감 문제. 한동안 활동이 없습니다.

FWIW, 나는 여전히이 문제가 있습니다 @benoitc :-\

장고 2.1.5
기니콘 19.8.1
제벤트 1.2.2
5개의 노드가 있는 AKS 1.15.7(표준 B2 - 2개의 vcore 및 2GB 메모리)
각각 다음을 포함하는 3개의 포드/도커 컨테이너:

    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에서는 실패했지만 이제 두 환경에서 모두 올바르게 작동합니다.