Gunicorn: 종료 신호가 없는데도 "부팅 작업자"가 무한 반복됩니다.

ssh -Docker 컨테이너에 입력하면 다음 오류가 발견되었습니다.

Illegal instruction (core dumped)

아마도 gunicorn은 오류를 삼키는 대신 이와 같은 오류를 표면화해야 할까요, 아니면 다르게 처리해야 할까요? 확실하지 않습니다. 다른 사람에게 도움이 될 수 있기 때문에 이것을 올릴 것이라고 생각했습니다!

문제를 신고해 주셔서 감사합니다!

어디서 이런 일이 발생하는지 알 수 있다면 매우 도움이 될 것입니다.

작업자가 종료할 때 로깅을 추가할 수 있습니다. 일반적으로 작업자 자체는 기록하지만 매우 갑자기 종료되면 기록되지 않습니다.

걱정 마!

이 스레드에 방금 추가한 Spacy에 문제가 있는 것 같습니다. https://github.com/explosion/spaCy/issues/1589

어쨌든 strace 확인하는 대로 SIGILL strace 가 발생합니다.

--- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7ff48bbe6cea} ---
+++ killed by SIGILL (core dumped) +++
Illegal instruction (core dumped)

나는 gunicorn이 이것을 식별하고 작업자를 환상적으로 다시 시작하는 것보다 오류를 기록할 수 있다면 좋을 것이라고 생각합니다. 그러나 나는 종료 코드가 어떻게 작동하는지 거의 알지 못합니다!

일부 종료 코드는 확실히 특별한 의미를 가지며 아마도 이를 기록할 수 있습니다.
http://tldp.org/LDP/abs/html/exitcodes.html

좋은 소리! 또한 종료 코드가 예약된 종료 코드(예: 이 경우)가 아닌 경우 설명 없이 기록될 수 있으면 멋질 것이므로 작업자가 실제로 종료되고 있음이 분명합니다.

나는 비슷한 문제가 있습니다. gunicorn은 http 요청을 할 때 항상 새로운 작업자를 부팅합니다. 나는 어떤 응답도받지 못하고 항상 새로운 작업자를 재부팅합니다. 두 http 요청의 추적 로그:

select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=510, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=32} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 510
lseek(8, 0, SEEK_CUR)                   = 0
close(8)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 840340})     = 1 (in [3], left {0, 840338})
read(3, ".", 1)                         = 1
read(3, 0x7f2682025fa0, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-q4aa72u7", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 8
fcntl(8, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-q4aa72u7", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-q4aa72u7")       = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(8, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(8, 0, SEEK_CUR)                   = 0
lseek(8, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 558
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 37381}[2017-12-28 17:50:23 +0000] [558] [INFO] Booting worker with pid: 558
) = 0 (Timeout)
select(4, [3], [], [], {1, 0}loading test-eu-ovh settings
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0}
)          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
select(4, [3], [], [], {1, 0})          = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=499, si_uid=0, si_status=SIGSEGV, si_utime=160, si_stime=31} ---
getpid()                                = 495
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
wait4(-1, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV && WCOREDUMP(s)}], WNOHANG, NULL) = 499
lseek(7, 0, SEEK_CUR)                   = 0
close(7)                                = 0
wait4(-1, 0x7ffd455ad844, WNOHANG, NULL) = 0
write(4, ".", 1)                        = 1
select(4, [3], [], [], {0, 450691})     = 1 (in [3], left {0, 450689})
read(3, ".", 1)                         = 1
read(3, 0x7f2682067de8, 1)              = -1 EAGAIN (Resource temporarily unavailable)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG, st_size=0, ...}) = 0
umask(0)                                = 022
getpid()                                = 495
open("/tmp/wgunicorn-5x9a40ca", O_RDWR|O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC, 0600) = 7
fcntl(7, F_SETFD, FD_CLOEXEC)           = 0
chown("/tmp/wgunicorn-5x9a40ca", 0, 0)  = 0
umask(022)                              = 0
unlink("/tmp/wgunicorn-5x9a40ca")       = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
ioctl(7, TIOCGWINSZ, 0x7ffd455b8e50)    = -1 ENOTTY (Not a tty)
lseek(7, 0, SEEK_CUR)                   = 0
lseek(7, 0, SEEK_CUR)                   = 0
rt_sigprocmask(SIG_BLOCK, ~[], [], 8)   = 0
fork()                                  = 579
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(0, NULL, NULL, NULL, {0, 8144}[2017-12-28 17:50:30 +0000] [579] [INFO] Booting worker with pid: 579
)  = 0 (Timeout)
select(4, [3], [], [], {1, 0})          = 0 (Timeout)
fstat(6, {st_mode=S_IFREG, st_size=0, ...}) = 0
fstat(7, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fstat(9, {st_mode=S_IFREG|01, st_size=0, ...}) = 0
fstat(8, {st_mode=S_IFREG|01, st_size=0, ...}) = 0

동일한 문제에 직면하고 있습니다. sync 작업자 유형에 대해 gunicorn 부팅이 몇 초 내에 반복됩니다. 작업자 시간 초과를 900 로 설정해도 도움이 되지 않습니다.

작업 전 로드에서 AWS S3에서 데이터를 다운로드하고 있습니다. 다양한 파일을 다운로드하는 데 약 1분 10초가 소요됩니다.

@sara-02 gunicorn을 실행하는 명령줄은 무엇입니까?

@benoitc gunicorn --pythonpath /src -b 0.0.0.0:$SERVICE_PORT --workers=1 -k sync -t $SERVICE_TIMEOUT flask_endpoint:app
여기에 제시

@sara-02 감사합니다.

이전 작업자가 실제로 종료됩니까, 아니면 온라인 상태로 유지되고 새 작업자가 생성됩니까? 디버그 로그는 또한 무엇을 보여줍니까?

로그는 botocore 로그와 혼합되어 있지만 이렇습니다.

[INFO] Booting worker with pid:  a
[INFO] Booting worker with pid:  b
[INFO] Booting worker with pid:  c

그러나 노동자는 죽임을 당했습니까? ps ax|grep gunicorn 명령을 반환하는 것은 무엇입니까?

@benoitc

그러나 한 가지 질문은 작업자 제한이 1로 설정되어 있을 때 2개의 gunicorn 프로세스가 표시되는 이유입니다. 주인은 한 사람이고 일꾼은 한 사람입니까?

1개의 중재자 프로세스(마스터)와 N개의 작업자 프로세스가 있습니다.

그래서 작업자가 부팅할 때마다 명령을 실행합니까? 그렇다면 이전 작업자가 죽고 새 작업자가 생성되는 것 같습니다. 조사하겠습니다.

@ sara-02 마지막으로 도커에서도 발생합니까?

@benoitc on docker-compose 예상대로 작동하지만 Openshift 에 동일한 코드를 입력하면 이 오류가 표시됩니다. 메모리 요구 사항을 늘리면 수정되었지만 docker-compose 를 통해 응용 프로그램을 실행할 때 limited 미만의 메모리를 사용하고 있습니다.

그냥 업데이트, 나에게 문제는 실제로 메모리 오류였으며 메모리 문제가 수정되면 수정되었습니다.

@benoitc
도커에서 5개의 gunicorn 작업자를 생성하는 동안 동일한 문제에 직면하고 있습니다.
@sara-02
메모리 오류의 원인을 어떻게 식별했습니까?

@gulshan-gaurav 2가지 도움이 되었습니다.
내 Pod에 할당된 메모리를 늘리고 충돌을 멈췄습니다. 둘째, Openshift Zabbix 로그를 확인했습니다.

@sara-02
내 스테이징 포드에서도 메모리에 로드하는 파일 + 모델이 50Mb이므로 2GB의 메모리는 5명의 작업자에게 충분해야 합니다.

@gulshan-gaurav 어떤 문제에 직면해 있습니까? 거기에 5 개의 프로세스가 있으면 좋아 보입니다 ....

나는 같은 문제가 있었다. 정확한 문제를 찾지 못했지만 python 3.5에서 3.6으로 업그레이드하면 해결되었습니다.

Docker 컨테이너에서 동일한 문제에 직면하고 있습니다. Gunicorn은 실패를 유발하지만 예외 또는 오류가 아닌 엔드포인트를 호출할 때마다 Gunicorn의 로그 파일에 출력할 때마다 새 작업자를 계속 보팅합니다. 내가 인쇄하도록 선택한 항목이 기록된 다음 갑자기 로그 파일에 "Booting worker with pid..."라고 표시됩니다.

도움이 된 한 단계는 환경 변수 PYTHONUNBUFFERED를 추가하는 것입니다. 그 전에는 인쇄문조차도 사라지고 Gunicorn의 로그에 저장되지 않았습니다.

앱의 다른 2개 엔드포인트가 올바르게 작동합니다.

나는 Gunicorn을 실행합니다 : gunicorn localhost:5000 --enable-stdio-inheritance --error-logfile /var/log/gunicorn/error.log --access-logfile /var/log/gunicorn/access. log --capture-output --log-level 디버그

이미 Python 3.6을 실행 중이고 메모리에 문제가 없는지 확인했습니다.

편집: Gunicorn의 잘못이 아니라 Python 문제인 것 같습니다. 일부 버전 불일치로 인해 특정 작업을 수행하는 동안 Python이 흔적 없이 죽었습니다.

작업자 노드가 계속 나오는 비슷한 문제에 직면하고 있습니다.
Booting worker with pid: 17636 . 이전 작업자 노드를 죽이고 있는지 또는 이전 작업자 노드가 여전히 존재하는지 모르겠습니다. 그러나 gunicorn 명령줄 인수에 언급된 작업자의 수는 3 - -workers=3 합니다. 또한 파이썬 버전 3.7을 사용하고 있습니다.

scikit-learn 종속성이 일치하지 않았지만 이를 해결한 후에도 여전히 동일한 무한 작업자가 발생합니다. 어떤 종류의 python 버전 불일치를 찾고 식별하는 방법은 무엇입니까?

OpenShift 내에서 동일한 문제에 직면하고 있습니다.

이미지에서 볼 수 있듯이 저는 6명의 작업자를 사용하고 있습니다(3개로 시도했습니다).
포드의 메모리를 늘렸는데 작동하지 않습니다.

빌드 구성:

어떤 아이디어라도?

감사 해요

elb 뒤에 aws에서 이것을 실행하고 있습니까? elb와 gunicorn 사이에 nginx ingress를 넣어 그 문제를 해결했습니다.

같은 문제가 있습니다.

flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Starting gunicorn 19.9.0
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Listening at: http://0.0.0.0:5000 (1)
flask_1  | [2019-02-23 09:08:17 +0000] [1] [INFO] Using worker: sync
flask_1  | [2019-02-23 09:08:17 +0000] [8] [INFO] Booting worker with pid: 8
flask_1  | [2019-02-23 09:08:19 +0000] [12] [INFO] Booting worker with pid: 12
flask_1  | [2019-02-23 09:08:19 +0000] [16] [INFO] Booting worker with pid: 16
flask_1  | [2019-02-23 09:08:20 +0000] [20] [INFO] Booting worker with pid: 20
flask_1  | [2019-02-23 09:08:21 +0000] [24] [INFO] Booting worker with pid: 24
flask_1  | [2019-02-23 09:08:22 +0000] [28] [INFO] Booting worker with pid: 28
flask_1  | [2019-02-23 09:08:23 +0000] [32] [INFO] Booting worker with pid: 32
flask_1  | [2019-02-23 09:08:25 +0000] [36] [INFO] Booting worker with pid: 36
flask_1  | [2019-02-23 09:08:26 +0000] [40] [INFO] Booting worker with pid: 40
flask_1  | [2019-02-23 09:08:27 +0000] [44] [INFO] Booting worker with pid: 44
flask_1  | [2019-02-23 09:08:29 +0000] [48] [INFO] Booting worker with pid: 48
flask_1  | [2019-02-23 09:08:30 +0000] [52] [INFO] Booting worker with pid: 52
flask_1  | [2019-02-23 09:08:31 +0000] [56] [INFO] Booting worker with pid: 56
flask_1  | [2019-02-23 09:08:33 +0000] [60] [INFO] Booting worker with pid: 60
flask_1  | [2019-02-23 09:08:34 +0000] [64] [INFO] Booting worker with pid: 64
flask_1  | [2019-02-23 09:08:35 +0000] [68] [INFO] Booting worker with pid: 68
flask_1  | [2019-02-23 09:08:36 +0000] [72] [INFO] Booting worker with pid: 72
flask_1  | [2019-02-23 09:08:37 +0000] [76] [INFO] Booting worker with pid: 76
flask_1  | [2019-02-23 09:08:38 +0000] [80] [INFO] Booting worker with pid: 80
flask_1  | [2019-02-23 09:08:40 +0000] [84] [INFO] Booting worker with pid: 84
flask_1  | [2019-02-23 09:08:41 +0000] [88] [INFO] Booting worker with pid: 88
flask_1  | [2019-02-23 09:08:42 +0000] [92] [INFO] Booting worker with pid: 92
flask_1  | [2019-02-23 09:08:44 +0000] [96] [INFO] Booting worker with pid: 96
flask_1  | [2019-02-23 09:08:45 +0000] [100] [INFO] Booting worker with pid: 100
flask_1  | [2019-02-23 09:08:45 +0000] [104] [INFO] Booting worker with pid: 104
flask_1  | [2019-02-23 09:08:46 +0000] [108] [INFO] Booting worker with pid: 108
flask_1  | [2019-02-23 09:08:47 +0000] [112] [INFO] Booting worker with pid: 112
flask_1  | [2019-02-23 09:08:48 +0000] [116] [INFO] Booting worker with pid: 116
flask_1  | [2019-02-23 09:08:49 +0000] [120] [INFO] Booting worker with pid: 120
flask_1  | [2019-02-23 09:08:50 +0000] [124] [INFO] Booting worker with pid: 124
flask_1  | [2019-02-23 09:08:52 +0000] [128] [INFO] Booting worker with pid: 128

다음은 docker-compose.yml .

version: '3'
services:
  flask:
    build: .
    command: gunicorn -b 0.0.0.0:5000 hello:app --reload
    environment:
      - FLASK_APP=hello.py
      - FLASK_DEBUG=1
      - PYTHONUNBUFFERED=True
    ports:
      - "5000:5000"
    volumes:
      - ./:/root

어떤 도커 이미지를 사용합니까?

@benoitc

[ec2-user@ip-172-31-85-181 web-services-course]$ docker --version
Docker version 18.06.1-ce, build e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
[ec2-user@ip-172-31-85-181 web-services-course]$ docker-compose --version
docker-compose version 1.23.2, build 1110ad01

다음 링크는 다음과 같습니다.

• Dockerfile https://github.com/glebmikha/web-services-course/blob/master/Dockerfile
• docker-compose.yml https://github.com/glebmikha/web-services-course/blob/master/docker-compose.yml

메모리 부족으로 인한 것일 수 있음을 알았습니다. 앱에 사용 가능한 것보다 더 많은 메모리가 필요합니다.
그러나 그것은 단지 가정입니다

정보: 3명의 작업자에 대한 gunicorn conf가 있을 때 정확히 이 동작을 관찰했지만 단일 코어 CPU가 있는 가상 머신에 코드를 배포했습니다. 그런 다음 2개의 코어를 사용하도록 환경을 변경하고 분명히 문제가 사라졌습니다.

INFO 수준에서만 'Worker exiting'이 발생하는 이유는 무엇입니까? 오류가 발생한 경우를 제외하고 작업자가 종료되는 이유는 무엇입니까? 내 작업자 스레드가 시스템 OOM 킬러에 의해 죽임을 당하고 있다는 사실을 확인하는 데 오랜 시간이 걸렸습니다. 위의 다른 사람들이 보고한 것처럼 때때로 'pid로 작업자 부팅'을 제외하고 로그에는 아무 것도 없습니다.

작업자가 종료하는 것이 반드시 오류는 아니기 때문에 --max-requests 와 같은 옵션으로 종료될 수 있습니다.

@HughWarrington 작업자가 비정상적인 종료 코드로 종료할 때 중재자에 로깅을 추가할 수 있습니다.

이에 대한 티켓을 열거나 이 코드를 reap_workers 메서드에 추가하는 PR을 제공할 수 있습니다.

나는 같은 문제가 있었고 해결책은 포드의 메모리 크기를 늘리는 것이 었습니다.

대형 spaCy 모델로 Docker에서 Gunicorn을 실행하는 것과 동일한 문제가 있었지만 오류 메시지 없이 작업자를 계속 다시 시작했습니다. 해결책은 Docker 컨테이너의 메모리를 늘리는 것입니다.

Kubernetes에서 실행되는 gevent(1.4.0) 작업자가 있는 최신(19.9.0) gunicorn에서 오늘 이 문제가 발생했습니다. 앱은 Falcon 앱이고 Docker 이미지는 3.7.3 태그가 있는 공식 Python 이미지 입니다.

[2019-07-05 00:07:42 +0000] [8] [INFO] Starting gunicorn 19.9.0
[2019-07-05 00:07:42 +0000] [8] [INFO] Listening at: http://0.0.0.0:5000 (8)
[2019-07-05 00:07:42 +0000] [8] [INFO] Using worker: gevent
[2019-07-05 00:07:43 +0000] [35] [INFO] Booting worker with pid: 35
[2019-07-05 00:07:43 +0000] [36] [INFO] Booting worker with pid: 36
[2019-07-05 00:07:43 +0000] [37] [INFO] Booting worker with pid: 37
[2019-07-05 00:07:43 +0000] [38] [INFO] Booting worker with pid: 38
[2019-07-05 00:07:43 +0000] [41] [INFO] Booting worker with pid: 41
[2019-07-05 00:07:43 +0000] [43] [INFO] Booting worker with pid: 43
[2019-07-05 00:07:43 +0000] [45] [INFO] Booting worker with pid: 45
[2019-07-05 00:07:43 +0000] [49] [INFO] Booting worker with pid: 49
[2019-07-05 00:07:43 +0000] [47] [INFO] Booting worker with pid: 47
[2019-07-05 00:07:49 +0000] [53] [INFO] Booting worker with pid: 53
[2019-07-05 00:07:50 +0000] [54] [INFO] Booting worker with pid: 54
[2019-07-05 00:07:53 +0000] [57] [INFO] Booting worker with pid: 57
[...]

포드에는 다음 리소스 설정이 있었습니다.

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

모든 것을 두 배로 늘리면 문제가 해결되었습니다.

한 가지 흥미로운 점은 호스트 시스템에서 dmesg 를 볼 때 SSL을 사용하여 서버에 액세스할 때 segfault -ing at libcrypto 임을 알 수 있다는 것입니다.

메모리에 큰 모델을 로드하지 않기 때문에 메모리는 문제가 되지 않는 것 같습니다. 작업자가 계속 충돌하고 오류 메시지가 표시되지 않습니다. 이에 대한 수정 사항이 있습니까?

나에게 같은 문제, 고칠 생각이 있습니까? gunicorn 19.9.0이 포함된 python 3.6.3

@MrKiven 당신의 앱은 무엇을 합니까? 요청과 같은 것을 사용하고 있습니까?

누군가 문제를 재현하는 방법을 제공할 수 있습니까?

파이프라인에서 실행되는 여러 구성 요소의 관리자입니다. 그들 중 일부는 동일한 시스템 또는 원격 시스템의 다른 구성 요소에 대한 HTTP 요청을 시작할 수 있습니다. 파이프라인의 일부 모듈은 병렬로 실행할 수 있지만 ThreadPoolExecutor를 사용하여 실행됩니다. 공유 객체를 사용하지 않지만 나중에 단일 결과로 집계되는 데이터 구조만 생성합니다.

불행히도 우리가 가지고 있는 시스템을 노출하지 않고 최소한의 예를 만들 수 있는지 확신할 수 없습니다.

요청은 때때로 새 프로세스를 분기하는 스레드로 많은 안전하지 않은 작업을 수행합니다. 다른 클라이언트를 사용하는 것이 좋습니다. 요청을 수행하는 데 사용하는 최소한 줄을 붙여넣을 수 있습니까? 시간 초과 기능을 사용하고 있습니까?

그 중 하나는 다음과 같습니다.

try:
     resp = requests.post(self._endpoint, json=request_data)

     if resp.status_code != 200:
          logger.critical("[Error]: status code is {}".format(resp.status_code))
          return None

     response = resp.json()
     return {"intent": response["intent"], "intent_ranking": response["intent_ranking"]}
except ConnectionError as exc:
     logger.critical("[Exception] {}".format(str(exc)))
     return None

감사 해요. 나는 그것에서 간단한 것을 만들려고 노력할 것입니다.

어쨌든 누군가가 예제나 단위 테스트로 동작을 재현하는 pr을 보내어 실제로 올바른 것을 수정하고 있는지 확인할 수 있다면 정말 좋을 것입니다.

누군가를 도울 수 있는지 확실하지 않지만 dockerized flask webapp을 실행하는 동안 동일한 문제가 발생하여 dockerfile의 기본 이미지를 python:3.6.9-alpine 업데이트하여 해결했습니다.

호스트의 Dmesg는 lilibpython3.6m.so.1.0에서 segfault를 표시했습니다.

[626278.653010] gunicorn[19965]: segfault at 70 ip 00007f6423e7faee sp 00007ffc4e9a2a38 error 4 in libpython3.6m.so.1.0[7f6423d8a000+194000]

내 도커 이미지는 python:3.6-alpine 기반으로 apk update 를 수행했습니다.

말했듯이 기본 이미지를 python:3.6.9-alpine 변경하면 해결되었습니다.

Flask + Docker + Kubernetes를 실행하는 것과 동일한 문제에 직면했습니다. CPU 및 메모리 제한을 늘리면 해결되었습니다.

같은 일이 우리에게도 일어났습니다. 리소스 제한을 늘리면 문제가 해결되었습니다.

이것은 macOS Catalina(컨테이너화되지 않음)에서 갑자기 발생했습니다.

나를 도운 것은 다음과 같습니다.

1. openssl 설치:

brew install openssl

1. 이것을 실행하고 ~/.zshrc :

export DYLD_LIBRARY_PATH=/usr/local/opt/openssl/lib:$DYLD_LIBRARY_PATH

출처: https://stackoverflow.com/a/58445755/5811984

비슷한 도전을 하고 있고 누군가가 나를 도울 수 있다면 감사할 것입니다.
이것이 내가 가진 것입니다.

" root@ubuntu-s-1vcpu-1gb-nyc1-01 :~# sudo systemctl status gunicorn.service ● gunicorn.service - gunicorn 데몬 로드됨: 로드됨(/etc/systemd/system/gunicorn.service, 비활성화됨, 공급업체 사전 설정: 활성화됨) 활성: 활성(실행 중) 이후 월요일 2020-02-24 07:48:04 UTC, 44분 전 메인 PID: 4846(gunicorn) 작업: 4(제한: 1151) CGroup: /system.slice/gunicorn.service ├ ─4846 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - ├─4866 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoproject /bin/gunicorn - ├─4868 /home/bright/djangoprojectdir/djangoprojectenv/bin/python /home/bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - └─4869 /home/bright/djangoprojectdir/djangoprojectenv/home/bin/pyth /bright/djangoprojectdir/djangoprojectenv/bin/gunicorn - 2월 24일 07:48:04 ubuntu-s-1vcpu-1gb-nyc1-01 systemd[1]: gunicorn 데몬이 중지되었습니다. 2월 24일 07:48:04 ubuntu-s-1vcpu -1GB-nyc1-01 systemd[1 ]: gunicorn 데몬을 시작했습니다. 2월 24일 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [INFO] gunicorn 시작 20.0.4 2월 24일 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [INFO] 듣기: unix:/run/gunicorn .soc 2월 24일 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4846] [INFO] 작업자 사용: sync 2월 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4866] [INFO] pid로 작업자 부팅: 4866 Feb 24 07:48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4868] [INFO] pid로 작업자 부팅: 4868 Feb 24 07 :48:05 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: [2020-02-24 07:48:05 +0000] [4869] [INFO] pid가 있는 부팅 작업자: 4869 Feb 24 08: 03:41 ubuntu-s-1vcpu-1gb-nyc1-01 gunicorn[4846]: - - [24/Feb/2020:08:03:41 +0000] "GET / HTTP/1.0" 400 26 "-" "Mozilla /5.0 (Wi 라인 1-20/20(종료)" 이 문제를 해결하는 데 도움을 줄 수 있는 사람이 있습니까?

@BrightNana dmesg 을 주고 gunicorn 오류가 있는지 확인할 수 있습니까?
dmesg | grep gunicorn 는 다른 오류를 필터링하는 데 도움이 될 수 있습니다.

안녕하십니까,
나는 gunicorn을 systemd 서비스로 제공하고 싶을 때 데비안 9에 같은 버그가 있습니다. CLI에서 시작하면 gunicorn이 오류 없이 실행됩니다.

dmesg | grep gunicorn 에서 추출:

journalctl 에서 발췌:
Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1054] [INFO] Booting worker with pid: 1054 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1057] [INFO] Booting worker with pid: 1057 Mär 12 07:01:06 build-server gunicorn[828]: [2020-03-12 07:01:06 +0100] [1060] [INFO] Booting worker with pid: 1060 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1064] [INFO] Booting worker with pid: 1064 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1067] [INFO] Booting worker with pid: 1067 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1070] [INFO] Booting worker with pid: 1070 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1073] [INFO] Booting worker with pid: 1073 Mär 12 07:01:07 build-server gunicorn[828]: [2020-03-12 07:01:07 +0100] [1076] [INFO] Booting worker with pid: 1076 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1079] [INFO] Booting worker with pid: 1079 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1082] [INFO] Booting worker with pid: 1082 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1085] [INFO] Booting worker with pid: 1085 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1088] [INFO] Booting worker with pid: 1088 Mär 12 07:01:08 build-server gunicorn[828]: [2020-03-12 07:01:08 +0100] [1091] [INFO] Booting worker with pid: 1091 Mär 12 07:01:09 build-server gunicorn[828]: [2020-03-12 07:01:09 +0100] [1094] [INFO] Booting worker with pid: 1094
systemctl status 에서 추출:
● api.service - API Server for BuildingChallenge served with Gunicorn Loaded: loaded (/etc/systemd/system/api.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2020-03-12 08:26:01 CET; 22min ago Main PID: 8150 (gunicorn) Tasks: 3 (limit: 4915) Memory: 37.7M (high: 100.0M max: 500.0M) CGroup: /system.slice/api.service ├─ 8150 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app ├─28936 /opt/api/venv/bin/python /opt/api/venv/bin/gunicorn --bind unix:api.sock wsgi:app └─28938 /usr/bin/python3 -Es /usr/bin/lsb_release -a Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28909] [INFO] Booting worker with pid: 28909 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28912] [INFO] Booting worker with pid: 28912 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28915] [INFO] Booting worker with pid: 28915 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28918] [INFO] Booting worker with pid: 28918 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28921] [INFO] Booting worker with pid: 28921 Mär 12 08:48:01 build-server gunicorn[8150]: [2020-03-12 08:48:01 +0100] [28924] [INFO] Booting worker with pid: 28924 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28927] [INFO] Booting worker with pid: 28927 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28930] [INFO] Booting worker with pid: 28930 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28933] [INFO] Booting worker with pid: 28933 Mär 12 08:48:02 build-server gunicorn[8150]: [2020-03-12 08:48:02 +0100] [28936] [INFO] Booting worker with pid: 28936

당신의 도움을 주셔서 감사합니다.

이러한 상황을 디버깅하는 데 도움이 될 수 있는 PR을 게시했습니다. 아무나 볼 수 있나요?
https://github.com/benoitc/gunicorn/pull/2315

Docker 내에서 실행되는 Flask 응용 프로그램과 동일한 문제가 있었습니다. 작업자는 증가하는 프로세스 ID로 무한히 다시 시작되었습니다.

문제는 저와 관련된 메모리였습니다. Docker에 허용되는 메모리를 늘리면 작업자가 효과적으로 생성되었습니다.

@tilgovi , 당신이 먼저 거기에 도착한 이후로 당신이 나의 변경 사항을 당신의 PR에 통합하고 싶다면 나는 상관하지 않습니다. 이것은 신호를 통해 살해되는 노동자를 다룰 것입니다.

@mildebrandt 한번 볼게요 감사합니다!

또한 Docker 컨테이너 내부에서 Gunicorn(20.0.4) + Gevent(1.5.0) + Flask를 사용하여 이 동작을 갑자기 보고 있습니다.

[  328.699160] gunicorn[5151]: segfault at 78 ip 00007fc1113c16be sp 00007ffce50452a0 error 4 in _greenlet.cpython-37m-x86_64-linux-gnu.so[7fc11138d000+3e000]

제 경우에는 segfault가 gevent에 의해 발생하는 것을 볼 수 있습니다. 이상한 점은 이 컨테이너가 5일 전에 제대로 작동했으며 그 이후로 코드가 변경되지 않고 라이브러리의 버전이 변경되지 않고 모두 특정 릴리스로 설정되었다는 것입니다. 다른 종속성의 버전을 약간 변경했을 수 있는 종속성으로 flask-mail을 제거했습니다.

gevent==1.5.0에서 gevent==20.9.0으로 업데이트하면 문제가 해결되었습니다.

@ifiddes 귀하의 문제는 관련이 없을 수 있습니다. 최신 버전의 greenlet과 이전 버전의 gevent 간에 ABI 호환성 문제가 발생했습니다. https://github.com/python-greenlet/greenlet/issues/178 참조

아, 감사합니다 @jamadden. 이 게시물은 부팅 작업자의 무한 생성을 검색할 때 찾을 수 있는 전부였지만 해당 문제와 해당 문제의 타이밍이 내 문제에 맞습니다.

Ubuntu 20.04 Server 가 있는 새 AWS 머신과 프로덕션에서 작동하는 동일한 코드에서 유사한 오류가 발생했습니다.

머신은 다른 프로덕션 머신과 마찬가지로 Ansible을 사용하여 구성되었습니다.

[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Current configuration:
  config: None
  bind: ['127.0.0.1:8000']
  backlog: 2048
  workers: 1
  worker_class: uvicorn.workers.UvicornWorker
  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: /var/www/realistico/app
  daemon: False
  raw_env: []
  pidfile: None
  worker_tmp_dir: None
  user: 1001
  group: 1001
  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: /var/www/realistico/logs/gunicorn/access.log
  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: /var/www/realistico/logs/gunicorn/error.log
  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
  dogstatsd_tags: 
  statsd_prefix: 
  proc_name: None
  default_proc_name: realistico.asgi:application
  pythonpath: None
  paste: None
  on_starting: <function OnStarting.on_starting at 0x7f7ba5fdd550>
  on_reload: <function OnReload.on_reload at 0x7f7ba5fdd670>
  when_ready: <function WhenReady.when_ready at 0x7f7ba5fdd790>
  pre_fork: <function Prefork.pre_fork at 0x7f7ba5fdd8b0>
  post_fork: <function Postfork.post_fork at 0x7f7ba5fdd9d0>
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7f7ba5fddaf0>
  worker_int: <function WorkerInt.worker_int at 0x7f7ba5fddc10>
  worker_abort: <function WorkerAbort.worker_abort at 0x7f7ba5fddd30>
  pre_exec: <function PreExec.pre_exec at 0x7f7ba5fdde50>
  pre_request: <function PreRequest.pre_request at 0x7f7ba5fddf70>
  post_request: <function PostRequest.post_request at 0x7f7ba5f6e040>
  child_exit: <function ChildExit.child_exit at 0x7f7ba5f6e160>
  worker_exit: <function WorkerExit.worker_exit at 0x7f7ba5f6e280>
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7f7ba5f6e3a0>
  on_exit: <function OnExit.on_exit at 0x7f7ba5f6e4c0>
  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: None
  raw_paste_global_conf: []
  strip_header_spaces: False
[2020-10-15 15:11:49 +0000] [18068] [INFO] Starting gunicorn 20.0.4
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] Arbiter booted
[2020-10-15 15:11:49 +0000] [18068] [INFO] Listening at: unix:/run/gunicorn.sock (18068)
[2020-10-15 15:11:49 +0000] [18068] [INFO] Using worker: uvicorn.workers.UvicornWorker
[2020-10-15 15:11:49 +0000] [18080] [INFO] Booting worker with pid: 18080
[2020-10-15 15:11:49 +0000] [18068] [DEBUG] 1 workers
[2020-10-15 15:11:51 +0000] [18083] [INFO] Booting worker with pid: 18083
[2020-10-15 15:11:53 +0000] [18086] [INFO] Booting worker with pid: 18086
...
[2020-10-15 15:12:09 +0000] [18120] [INFO] Booting worker with pid: 18120
[2020-10-15 15:12:11 +0000] [18123] [INFO] Booting worker with pid: 18123

이 문제를 성공하지 않고(그리고 로그에 대한 오류 없이) 해결하려고 많은 시간을 허비한 후 이 Hello World를 사용해 보았고 다음 오류를 발견했습니다.

ModuleNotFoundError: No module named 'httptools'

httptools 설치 후 Hello world 응용 프로그램이 제대로 작동하고 예기치 않게 내 응용 프로그램도 작동합니다.

왜 오류가 기록되지 않았는지 또는 이 라이브러리가 다른 컴퓨터에는 설치되었지만 새 컴퓨터에는 설치되지 않은 이유를 알 수 없지만 이 방법으로 문제가 해결되었습니다.

최근에 이런 일이 발생하고 모든 CPU를 소비하여 그것이 있었던 kubernetes 노드를 중단하십시오. dmesg 에 대한 힌트 덕분에 결국 오류를 찾았습니다.

[225027.348869] traps: python[44796] general protection ip:7f8bd8f8f8b0 sp:7ffc21a0b370 error:0 in libpython3.7m.so.1.0[7f8bd8dca000+2d9000]

결국 내 문제는 https://github.com/python-greenlet/greenlet/issues/178의 또 다른 인스턴스였으며 gunicorn, gevent 및 greenlet을 최신 버전으로 업데이트하여 해결되었습니다.

이러한 유형의 예외는 파이썬 로그를 생성하지 않고 잡을 수 없으며 종료 코드 0을 반환하고 발생 시 시스템을 중단시킬 수 있으므로 관리하기가 상당히 어렵습니다.

나는 gunicorn이 이러한 특성의 빠른 충돌 반복을 감지하고

• 새로운 작업자 생성을 포기하거나 속도 제한
• 사람들에게 이 문제와 https://github.com/python-greenlet/greenlet/issues/178 을 알려주는 유용한 메시지를 제공

아마도 max_consecutive_startup_crashes 이고 기본값은 num_workers * 10 입니까?

#2504에서 크래시 루프 기능 요청을 추적해 보겠습니다. #2315에 추가 로그인을 위한 PR도 있습니다. 모든 사람이 문제를 디버깅한 것 같기 때문에 이 문제를 닫겠습니다. 이제 앞으로 다른 사람들을 돕기 위한 몇 가지 기능 요청과 개선 사항이 있습니다. 감사합니다!