Gunicorn: timeout 및 graceful_timeout 작동 내용/방법을 명확히 합니다.

에 만든 2017년 04월 03일 · 30코멘트 · 출처: benoitc/gunicorn

(여기서 독백에 대해 유감스럽게 생각합니다. 간단한 일이 복잡해져서 결국 스택을 파헤쳤습니다. 그러나 내가 문서화한 내용이 독자에게 도움이 되기를 바랍니다.)

내가 이해했듯이 기본적으로 :

요청 처리 30 초( timeout 로 구성 가능) 후 gunicorn 마스터 프로세스는 SIGTERM 를 작업자 프로세스에 전송하여 정상적인 재시작을 시작합니다.
작업자가 다른 30 초 동안 종료되지 않으면( graceful_timeout 로 구성 가능) 마스터 프로세스는 SIGKILL 를 보냅니다. graceful_timeout 기간(https://github.com/benoitc/gunicorn/commit/d1a09732256fa8db900a1fe75a71466cf2645ef9) 동안 작업자가 정상적으로 종료 _does_할 때도 이 신호가 전송되는 것 같습니다.

질문:

신호가 정확합니까?
gunicorn(동기화) 작업자가 이러한 신호를 수신하면 실제로 어떻게 됩니까? 신호가 포착되었고 어떤 일이 일어나야 한다는 것을 WSGI 앱에 어떻게 알립니까?
예를 들어 Flask는 SIGTERM 신호를 어떻게 처리합니까? 실제로 요청 처리 중에 어떤 일이 발생합니까? 요청 처리가 완료된 후 종료해야 하는 WSGI 응용 프로그램(werkzeug 수준에서) 플래그를 설정합니까? 아니면 SIGTERM 가 이미 진행 중인 요청 처리에 영향을 미치고 있습니까? IO 연결을 종료하거나 요청 처리 속도를 높이기 위한 것...?

SIGKILL 에서 요청 처리가 강제로 중단된 것 같습니다.

실제로 작동하는 방식을 이해하면 이에 대한 문서를 개선하기 위해 작은 PR을 제출할 수 있습니다.

Discussion Documentation

출처

tuukkamustonen

👍8

가장 유용한 댓글

@tuukkamustonen --timeout 는 요청 시간 초과를 의미하지 않습니다. 그것은 노동자를 위한 생존 체크를 의미합니다. 동기화 작업자의 경우 작업자가 요청을 처리하는 것 외에는 아무 것도 할 수 없기 때문에 요청 시간 초과로 작동합니다. 비동기식 작업자는 장기 실행 요청을 처리하는 동안에도 하트비트이므로 작업자가 차단/동결하지 않는 한 종료되지 않습니다.

다른 사람들이 이것을 혼동하는 경우 이름을 변경하는 것이 좋습니다.

tilgovi 에 2017년 08월 09일

👍12

모든 30 댓글

흠, https://github.com/benoitc/gunicorn/issues/1236#issuecomment -254059927 요청 처리가 완료된 후 작업자를 종료하도록 설정하는 SIGTERM 에 대한 내 가정을 확인하는 것 같습니다(그리고 작업자가 수락하지 않도록 설정) 모든 새로운 연결).

tuukkamustonen 에 2017년 04월 03일

timeout 및 graceful_timeout 를 해석한 방식이 잘못된 것 같습니다. 두 기간 모두 실제로 요청 처리가 시작된 시간을 나타냅니다. 따라서 기본적으로 두 설정 모두 30 초로 설정되어 있으므로 정상적인 재시작이 활성화되지 않습니다. --graceful-timeout 15 --timeout 30 와 같은 작업을 수행하면 정상적인 재시작이 15초에 시작되고 그 전에 요청이 완료되지 않은 경우 작업자가 30초에 강제 종료됩니다.

그런데 graceful_timeout 와 timeout 사이에 응답이 돌아오면 결국 작업자가 다시 시작되지 않는 것 같습니다. 안 돼?

app.py 로 테스트했습니다.

import time
from flask import Flask

app = Flask(__name__)

@app.route('/foo')
def foo():
    time.sleep(3)
    return 'ok'

그 다음에:

12:51 $ gunicorn app:app --timeout 5 --graceful-timeout 1
[2017-04-03 12:51:37 +0300] [356] [INFO] Starting gunicorn 19.6.0
[2017-04-03 12:51:37 +0300] [356] [INFO] Listening at: http://127.0.0.1:8000 (356)
[2017-04-03 12:51:37 +0300] [356] [INFO] Using worker: sync
[2017-04-03 12:51:37 +0300] [359] [INFO] Booting worker with pid: 359

그런 다음 3초 후에 반환되는 curl localhost:8000/foo 를 보냅니다. 그러나 gunicorn에서는 아무 일도 일어나지 않습니다. 정상적인 재시작이 시작되거나 발생한 흔적이 보이지 않습니까?

tuukkamustonen 에 2017년 04월 03일

timeout 에서 SystemExit(1,) 가 발생하여 Flask의 현재 요청 처리가 중단된 것 같습니다. 어떤 코드나 신호가 그것을 생성하는지 말할 수 없습니다.

이 예외는 Flask 스택을 통해 발생하고 모든 teardown_request 핸들러가 이를 포착합니다. 무언가를 기록할 시간은 충분하지만 time.sleep(1) 또는 처리기에서 시간이 많이 걸리는 다른 작업을 수행하면 자동으로 종료됩니다. 프로세스가 실제로 강제 종료되기까지 100-200ms의 시간이 있었던 것 같으며 이 지연이 무엇인지 궁금합니다. 정상적인 시간 초과가 아니며 해당 설정은 지연에 영향을 미치지 않습니다. SystemExit 스택을 통해 던져지는 대신 프로세스가 강제 종료될 것으로 예상하지만 어쨌든 잠재적으로 프로세스가 공중에서 종료됩니다.

사실, 나는 graceful_timeout 가 아무것도 하지 않는 것을 볼 수 있습니다 - 동기화 작업자에 대해 지원되지 않거나 "독립 실행형"으로 작동하지 않을 수 있습니다(또는 timeout 와 함께) - 만 SIGTERM 를 수동으로 보낼 때?

또한 이상한 점은 https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L392 가 graceful 플래그를 전혀 확인하지 않는다는 것입니다. https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L390 은 self.WORKERS 이 비어 있으므로 비정상 정지를 할 때 우아한 시간 초과가 기다리지 않도록 합니다.

tuukkamustonen 에 2017년 04월 03일

@benoitc @tilgovi 여기에서 손을 내밀어 주시겠습니까? 위의 내 글이 의미가 있기를 바랍니다 ...

tuukkamustonen 에 2017년 04월 06일

@tuco86 graceful timeout 는 중재자를 종료하거나 업그레이드(USR2)하거나 중재자에게 HUP 신호를 보내거나 작업자에게 QUIT 신호를 보낼 때만 사용할 수 있습니다. 즉, 동작이 정상일 때만 사용됩니다.

시간 초과는 바쁜 작업자가 다른 요청을 차단하는 것을 방지하기 위한 것입니다. timeout 보다 짧은 시간 내에 중재자에게 알리지 않으면 작업자는 단순히 종료되고 클라이언트와의 연결이 닫힙니다.

benoitc 에 2017년 04월 17일

어, 알았어. timeout 는 다음과 같은 경우에 효과가 있습니까?

중재자 종료, 업그레이드(USR2), 중재자에게 HUP 신호 보내기 또는 작업자에게 QUIT 신호 보내기

내 말은, 작업자가 graceful_timeout 에 종료되지 않으면 - 그 후 timeout 가 시작되고 작업자가 강제로 죽임을 당하거나 SIGQUIT 를 호출하는 것은 사용자에게 달려 있습니다.

작업자에게 QUIT 신호

여기서 TERM 를 의미했다고 가정합니다( QUIT 는 마스터와 작업자 모두에 대해 _빠른 종료_로 문서화되어 있으므로)?

tuukkamustonen 에 2017년 04월 17일

작업자가 정상적인 시간 동안 종료하지 않으면 다른 지연 없이 종료됩니다.

benoitc 에 2017년 04월 21일

당연하지. 정리해주셔서 감사합니다!

tuukkamustonen 에 2017년 04월 21일

@benoitc 이 오래된 티켓의 맥락에서 질문 - timeout 문서의 마지막 문장은 실제로 무엇을 의미합니까?

일반적으로 30초로 설정됩니다. 동기화 작업자에 대한 영향을 확신하는 경우에만 이 값을 눈에 띄게 높게 설정하십시오. 비 동기화 작업자의 경우 작업자 프로세스가 여전히 통신 중이며 단일 요청을 처리하는 데 필요한 시간 길이와 관련이 없음을 의미합니다.

저는 영어가 모국어가 아니라서 이해하기 어렵습니다. timeout gthread 비동기 작업자에 대해 지원되지 않는다는 것을 의미합니까? )?

tuukkamustonen 에 2017년 08월 09일

👍1

다른 사람들이 이것을 혼동하는 경우 이름을 변경하는 것이 좋습니다.

tilgovi 에 2017년 08월 09일

👍12

@tilgovi timeout 는 괜찮지만 worker_timeout 와 같은 것이 더 설명적일 수 있습니다. timeout 및 graceful_timeout 가 문서에서 서로 옆에 선언되어 있기 때문에 처음에는 혼란스러웠습니다. 그래서 내 두뇌는 그것들이 밀접하게 연결되어 있다고 가정했지만 실제로는 그렇지 않았습니다.

동기화 작업자의 경우 작업자가 요청을 처리하는 것 외에는 아무 것도 할 수 없기 때문에 요청 시간 초과로 작동합니다. 비동기식 작업자는 장기 실행 요청을 처리하는 동안에도 하트비트이므로 작업자가 차단/동결하지 않는 한 종료되지 않습니다.

timeout 가 동기화되지 않은 작업자와 함께 시작되는 경우의 예가 있습니까? 절대로 일어나서는 안 되는 일입니까? 작업자를 차단/정지시키는 버그가 있는 경우에만 가능합니까?

tuukkamustonen 에 2017년 08월 10일

맞습니다. 이벤트 루프 코어에 의존하는 비동기 작업자는 제한 시간 내에 양보하지 않는 CPU 집약적 절차를 수행할 수 있습니다.

tilgovi 에 2017년 08월 10일

즉, 버그뿐만이 아닙니다. 그러나 때때로 asyncio 프로토콜이 더 적절할 때 차단 I/O 함수에 대한 호출과 같은 버그를 나타낼 수 있습니다.

tilgovi 에 2017년 08월 10일

CPU 집약적인 작업에 갇힌 것이 좋은 예입니다. 감사합니다.

비동기 코드에서 차단 I/O를 호출하는 것도 하나지만 이 컨텍스트에 어떻게 적용되는지 잘 모르겠습니다. 차단 코드가 있는 기존 Flask 앱을 실행하고 있지만 비동기 작업자( gthread ) 어떤 종류의 원숭이 패치도 없습니다. 그리고 그것은 잘 작동합니다. 나는 이것이 더 이상 이 티켓의 맥락에 있지 않다는 것을 알고 있지만 이와 같은 비동기/동기화 코드를 혼합하고 일치시키면 문제가 발생하지 않습니까?

tuukkamustonen 에 2017년 08월 10일

또한 심장 박동 간격은 무엇입니까? 동기화되지 않은 작업자와 함께 timeout 에 사용할 정상적인 값은 무엇입니까?

tuukkamustonen 에 2017년 08월 10일

gthread 작업자는 비동기적이지 않지만 하트비트에 대한 기본 스레드가 있으므로 시간 초과되지 않습니다. 해당 작업자의 경우 작업자가 매우 오버로드되거나 더 가능성이 높은 C 확장 모듈을 호출하여 GIL을 해제하지 않는 한 시간 초과가 표시되지 않습니다.

작업자 시간 초과가 표시되기 시작하지 않는 한 시간 초과를 변경할 필요가 없을 것입니다.

tilgovi 에 2017년 08월 10일

괜찮은. 한 가지 더:

gthread 작업자는 비동기식이 아닙니다.

gthread 작업자가 비동기가 아니라 http://docs.gunicorn.org/en/stable/design.html#asyncio -workers에 "AsyncIO" 작업자로 나열되어 있다는 것이 약간 혼란스러울 수 있습니다. 그 외에 "스레드"를 사용하면 asyncio가 필요하지 않으므로 독자에게 질문을 제기하기도 합니다. 순진한 사용자의 관점에서 이것을 말하는 것만으로도 기술적으로 충분히 근거가 있다고 확신합니다.

간단히 말해서 gthread 작업자는 asyncio lib로 구현되지만 동기화 코드를 처리하기 위해 스레드를 생성합니다. 틀렸다면 정정해주세요.

tuukkamustonen 에 2017년 08월 10일

물어봐주셔서 기뻐요!

스레드 작업자는 asyncio를 사용하지 않으며 기본 비동기 작업자 클래스에서 상속하지 않습니다.

문서를 명확히 해야 합니다. 작업자 시간 초과가 동시에 처리되어 긴 요청 및 동시 요청을 처리하는 기능과 관련하여 동기화 작업자보다 비동기 작업자처럼 작동하기 때문에 비동기로 나열되었을 수 있다고 생각합니다.

문서를 명확히 하고 모든 작업자를 더 정확하게 설명하도록 하는 것이 좋습니다.

tilgovi 에 2017년 08월 10일

👍4

예, gthreads 작업자는 asyncio 작업자에 나열되지 않아야 합니다. 각 작업자의 디자인을 설명하는 섹션이 있는 것이 더 나을까요?

benoitc 에 2017년 08월 11일

작업자 유형 및 시간 초과에 대한 섹션을 명확히 하기 위해 작업으로 추적할 수 있도록 이것을 다시 엽니다.

tilgovi 에 2017년 08월 21일

@틸고비

--timeout은 요청 시간 초과를 의미하지 않습니다. 그것은 노동자를 위한 생존 체크를 의미합니다. 동기화 작업자의 경우 작업자가 요청을 처리하는 것 외에는 아무 것도 할 수 없기 때문에 요청 시간 초과로 작동합니다. 비동기식 작업자는 장기 실행 요청을 처리하는 동안에도 하트비트이므로 작업자가 차단/동결하지 않는 한 종료되지 않습니다.

비동기 작업자에 사용할 수 있는 요청 시간 초과 옵션이 있습니까? 즉, Arbiter가 지정된 시간 내에 요청을 처리하지 않은 작업자를 죽이는 방법은 무엇입니까?

aschatten 에 2018년 01월 09일

@aschatten 불행히도 없습니다. #1658도 참조하십시오.

tilgovi 에 2018년 01월 09일

지정된 시간 내에 요청을 처리하지 않은 작업자 죽이기

작업자가 여러 요청을 동시에 처리할 수 있으므로 하나의 요청 시간 초과로 인해 전체 작업자를 죽이는 것은 매우 극단적으로 들립니다. 다른 모든 요청이 헛되이 죽임을 당하지 않습니까?

uWSGI가 2.1 정도에서 스레드 기반 킬을 도입할 계획이었던 것을 기억합니다. 아마도 동기화/스레드 작업자에게만 적용되는 것일 수도 있지만(그리고 이에 대한 제 기억은 모호합니다).

tuukkamustonen 에 2018년 01월 09일

👍2

작업자가 여러 요청을 동시에 처리할 수 있으므로 하나의 요청 시간 초과로 인해 전체 작업자를 죽이는 것은 매우 극단적으로 들립니다. 그렇게 하면 다른 모든 요청이 헛되이 죽게 되지 않을까요?

접근 방식은 max_request 와 동일할 수 있습니다. 여기서 모든 작업자 유형에 대해 별도의 구현이 있습니다.

aschatten 에 2018년 01월 09일

👍1

우리는 이번 주에 릴리스를 작업 중이며, 그 시점이 _어쩌면_ R20으로 분기할 시간이며, 여기서 몇 가지 주요 사항을 다룰 계획입니다. 현재 시간 초과를 모든 작업자 유형에 대한 적절한 요청 시간 초과로 만드는 적절한 시간일 수 있습니다.

tilgovi 에 2018년 01월 09일

👍1

시간 초과가 어떻게 작동하는지 이해하려고 노력하고 있고 이것이 버그인지 아닌지 확실하지 않기 때문에 별도의 문제를 제출하는 대신 여기에 댓글을 남깁니다.

내가보고있는 IMO 예기치 않은 동작은 다음과 같습니다.

모든 최대 요청의 요청(이후 작업자가 다시 시작됨)은 시간 초과되지만 다른 요청은 성공적으로 완료됩니다. 아래 예에서 4개의 요청이 수행되고 요청 1, 2, 4는 성공하지만 요청 3은 실패합니다.

Gunicorn: timeout 및 graceful_timeout 작동 내용/방법을 명확히 합니다.

가장 유용한 댓글

모든 30 댓글

관련 문제