Gunicorn: Heroku에서 >13k 응답을 반환할 때 POST 실패

정말 유용한 보고서, @erjiang 감사합니다.

테스트할 heroku 계정이 없습니다. 그런 계정을 가진 사람이 테스트할 수 있습니까? cc @tilgovi @kennethreitz

기쁘지만 아마 곧 얻을 수 없을 것입니다.

빠른 온전성 검사로 로컬에서 실행하고 웨이트리스와 gunicorn을 비교하기 위해 curl로 몇 가지를 확인했습니다.

• [x] 콘텐츠 길이 동일
• [x] 동일한 본문 내용
• [x] 동일한 전송 인코딩(둘 중 하나가 청크를 지정하지 않고 둘 다 Content-Length 사용)

다음으로 TCP 수준에서 차이가 있는지 궁금합니다. 나는 그것들을 tcpdump하고 비린내가 나는 것을 알아차릴 것입니다.

나는 같은 컬 라인으로도 gunicorn이 연결을 끊지 만 웨이트리스가 열어 둡니다. 아직 그 단서가 없지만 내가 볼 수 있었던 것은 _유일한_ 다른 점이었습니다.

@tilgovi 웨이트리스에게 보이는 동작을 스레드 작업자로 재현할 수 있다고 생각합니다. 어쨌든 이렇게 처리해주셔서 감사합니다 :)

안녕하세요 여러분,
같은 문제가 발생했습니다. 이 문제를 더 자세히 검토할 기회가 있으신가요?
@tilgovi @erjiang @benoitc

건배
격언

@maximkgn 플라스크도 사용하고 있습니까? 자세한 내용은?

장고 1.7을 사용하고 있습니다.
우리는 항상 13k보다 긴 특정 포스트 응답을 가지고 있었고 ~0.5의 특정 확률로 클라이언트의 응답은 13k보다 약간 잘렸습니다. heroku 로그에서 동일한 h18 오류를 보았고 Python 코드에서 오류가 발생하지 않는지 확인한 후 heroku와 Python 사이의 gunicorn 계층에서 발생한다고 결론을 내려야 했습니다.
우리가 waitress/uwgi로 전환했을 때 버그가 발생하지 않았습니다.

@maximkgn --threads 설정을 사용하면 어떻게 됩니까?

누구든지 이것을 테스트 할 수 있습니까?

플라스크와 gunicorn(테스트 버전 19.3 및 19.4.5)에 동일한 문제가 있습니다. @benoitc 1, 2 및 4 스레드(

어떤 식으로든 이것을 테스트하는 데 도움을 줄 수 있는지 알려주십시오.

@cbaines 요청이 어떻게 생겼나요?

Friendpaste는 1백만 개 이상의 게시물을 수락할 수 있습니다.... 그래서 gunicorn 내부에는 제한이 없습니다.

답이 없었습니다. 재현할 수 없으므로 문제를 닫습니다. 필요한 경우 자유롭게 다시 엽니다.

Flask 1.0.2 및 gunicorn 19.9.0을 포함하도록 종속성을 업데이트한 후에도 계속 재생됩니다. 하지만 이것에 대해 Heroku의 누군가의 관심을 받는 것이 좋을 수도 있습니다. 그들은 헌신적인 Python 사람들이 있다고 들었습니다.

여기에서 최신 커밋을 참조하십시오: https://github.com/erjiang/gunicorn-issue/

또한 정기적으로 대규모 GET 요청에 대해 이 H18 오류를 수신하고 있습니다.

웨이트리스로 전환하면 문제가 해결되었습니다. gunicorn이 그것을 생성하는 이유는 확실하지 않지만 동일한 정확한 코드가 실행되고 있습니다.

응답 본문은 21.54KB입니다.

Flask 1.0.2 및 gunicorn 19.9.0을 포함하도록 종속성을 업데이트한 후에도 계속 재생됩니다. 하지만 이것에 대해 Heroku의 누군가의 관심을 받는 것이 좋을 수도 있습니다. 그들은 헌신적인 Python 사람들이 있다고 들었습니다.

여기에서 최신 커밋을 참조하십시오: https://github.com/erjiang/gunicorn-issue/

Heroku에서 지원 티켓을 만들었습니다. 유용한 것이 있으면 여기에서 업데이트할 것입니다.

@benoitc 는 @erjiang 이 재현 가능한 예를 제공한 것처럼 보입니다. 이 백업을 열 수 있습니까?

다시 열었습니다. 내가 스스로 할당하고 가능한 한 살펴보겠습니다.

Flask 1.0.2 및 gunicorn 19.9.0을 포함하도록 종속성을 업데이트한 후에도 계속 재생됩니다. 하지만 이것에 대해 Heroku의 누군가의 관심을 받는 것이 좋을 수도 있습니다. 그들은 헌신적인 Python 사람들이 있다고 들었습니다.
여기에서 최신 커밋을 참조하십시오: https://github.com/erjiang/gunicorn-issue/

Heroku에서 지원 티켓을 만들었습니다. 유용한 것이 있으면 여기에서 업데이트할 것입니다.

heroku에서 답장을 받았습니까?

https://github.com/erjiang/gunicorn-issue (gunicorn 19.9.0, Python 2.7.14, sync worker, --workers 4 사용)에서 테스트 케이스를 사용하여 재현할 수 있었습니다. 참고로 gunicorn의 액세스 로그 출력은 HTTP 200을 반환했다고 보고합니다.

Python 3.7.3 + gunicorn master 로 업데이트하고 --workers 1 줄이는 것은 재현성에 영향을 미치지 않았지만 동기화 작업자에서 gevent로 전환하면 오류가 덜 자주 발생합니다(여전히 발생했지만). --log-level debug 사용해도 중요한 것은 나타나지 않았습니다(요청 중 유일한 추가 출력은 [DEBUG] POST /test1 행이었습니다).

다음으로 --spew 시도했지만 문제가 더 이상 재현되지 않습니다. 이것은 추가하려고 저를 주도 time.sleep(1) 전과 resp.close() 여기에 유사 문제를 방지하는합니다.

따라서 close() 시간에 소켓 보내기 버퍼가 비어 있지 않을 수 있으므로 응답이 손실될 수 있습니다.

참고: close() 는 연결과 관련된 리소스를 해제하지만 연결을 즉시 닫을 필요는 없습니다. 적시에 연결을 종료하려면 shutdown() 전에 close() shutdown() 를 호출하십시오.

(https://docs.python.org/3/library/socket.html#socket.socket.close 참조)

여기에 sock.close() 앞에 sock.shutdown(socket.SHUT_RDWR) ( docs )를 추가하면 문제가 해결되었습니다. 대안 수정은 아마도 SO_LINGER 를 사용하는 것일 수 있지만, 제가 읽은 바에 따르면 장단점이 있습니다.

이 주제에 대한 문서는 찾기 어렵지만 다음을 찾았습니다.
https://stackoverflow.com/questions/8874021/close-socket-directly-after-send-unsafe
https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable

도움이 되기를 바랍니다 :-)

전체 STR:

1. https://signup.heroku.com 에서 무료 Heroku 계정을 만드십시오.
2. Heroku CLI 설치(https://devcenter.heroku.com/articles/heroku-cli 참조)
3. heroku login 사용하여 CLI에 로그인합니다.
4. git clone https://github.com/erjiang/gunicorn-issue && cd gunicorn-issue
5. heroku create (이것은 무작위로 생성된 이름을 가진 무료 Heroku 앱을 생성하고 heroku 라는 git remote를 구성합니다)
6. git push heroku master
7. curl --data "foo=bar" https://YOUR_GENERATED_APP_NAME.herokuapp.com/test1 (75% 이상 실패)
8. 완료되면 heroku destroy 를 실행하여 앱을 삭제합니다.

@edmorley 같은 @tilgovi 사운드는 무엇이 잘못되었는지의 그럴듯한 설명을 생산했다. 올바른 수정 사항이 무엇인지 살펴보고 알 수 있습니까? sock.shutdown() 를 추가하기 위해 PR을 제출할 수도 있지만 이것이 올바른 수정인지 또는 다른 상황에 부정적인 영향을 미칠지 여부를 말할 만큼 충분히 모릅니다.

안녕하세요, 503KB 응답 크기로 동일한 문제가 발생했습니다. 응답 데이터는 JSON 배열입니다.
관찰된 동작 은 다음과 같습니다.

1. 잘린 응답 본문이 표시되고 http 클라이언트(Chrome, curl)가 여전히 응답을 기다리고 있습니다.
2. 요청의 ~75%는 120-130초 사이의 응답 시간을 경험합니다. 나머지 요청은 400ms 이내에 해결됩니다.
3. 응답 크기가 작은 요청은 빠릅니다.

다음 두 가지 모두

1. Windows 10에서 로컬 Docker 설치
2. AWS ECS에서 도커 컨테이너 실행

런타임 환경 설정
meinheld-gunicorn-docker 이미지는 Python 3.6.7, Flask 1.0.2, flask-restplus 0.12.1, 간단한 Flask-caching을 사용 하여 _python3.6_으로 태그가 지정되었습니다.

Docker 구성 : 3개의 CPU, RAM 1024MB

Gunicorn 구성 :

• 작업자 = 2*CPU + 1(문서에서 권장)
• 스레드=1(2*CPU 스레드와 동일한 동작)
• worker_class=" egg:meinheld#gunicorn_worker "

https://github.com/benoitc/gunicorn/issues/2015에서 다른 사람이 meinheld 작업자 교수형에 문제가 있었고 다른 작업자 유형을 사용하여 문제를 해결했습니다. 일반적인 문제가 있는지 궁금합니다. @stapetro 다른 작업자를 시도할 수 있습니까?

안녕하세요 @jamadden 입니다 .
귀하의 제안으로 문제가 해결되었습니다. _gevent_ 및 _gthread_ 작업자 클래스에는 문제가 없습니다. 나는 meinheld에서 멀리 이사했습니다. 빠른 답변과 도움 감사합니다! :)

전체 STR:

1. https://signup.heroku.com 에서 무료 Heroku 계정을 만드십시오.
2. Heroku CLI 설치(https://devcenter.heroku.com/articles/heroku-cli 참조)
3. heroku login 사용하여 CLI에 로그인합니다.
4. git clone https://github.com/erjiang/gunicorn-issue && cd gunicorn-issue
5. heroku create (이것은 무작위로 생성된 이름을 가진 무료 Heroku 앱을 생성하고 heroku 라는 git remote를 구성합니다)
6. git push heroku master
7. curl --data "foo=bar" https://YOUR_GENERATED_APP_NAME.herokuapp.com/test1 (75% 이상 실패)
8. 완료되면 heroku destroy 를 실행하여 앱을 삭제합니다.

내 앱에서 매우 유사한 동작이 있었고 curl --data 대신 curl -H를 사용할 때(GET 요청이기 때문에) 내 앱(Django, Gunicorn, Heruko)에서 작동한다는 것을 발견했습니다. 나는 gunicorn-issue 앱에서 테스트하지 않았습니다. 이것이 누군가에게 유용할 수 있다고 생각했습니다.

@mikkelhn 네 . Flask/Flask RestPlus 및 Gunicorn이 있는 앱은 다음과 같이 작동합니다. POST 요청에 응답하면 [페이로드 > 13k인 경우] 503 오류 가 발생하지만 앱이 GET에 응답하면 오류 하지 않습니다 . 정확히 같은 코드!
누구든지이 매우 성가신 행동을 설명 할 수 있습니까? 웨이트리스로 전환하는 것이 이 문제를 해결하는 유일한 해결 방법입니까? Gunicorn을 "손으로" 수정하는 것은 실행 가능한 솔루션이 아니라고 생각합니다...

나는 close() 전에 shutdown()을 호출하기 위해 PR을 열었습니다. 솔직히 Heroku에서 Gunicorn이 기본적으로 고장났을 때 Heroku가 Gunicorn을 계속 추천하는 것은 약간 엉뚱합니다.

@erijang이 올바르게 기술한 것처럼 Heroku가 Gunicorn을 사용할 수 없을 때 Gunicorn을 권장하는 경우: Gunicorn에 대한 간단하고 실행 가능한 대안은 무엇입니까(및 Heroku에서 가장 잘 구성하는 방법)?
AFAIK, 많은 고객이 Heroku를 선택하는 이유는 서버 아키텍처 및 구성 세부 정보에 대한 깊은 지식이 필요하지 않기 때문입니다... :|

@RinaldoNani 무슨

@benoitc 이 문제는 다음에서 언급한 것처럼 여러 작업자 유형에 영향을 줍니다.
https://github.com/benoitc/gunicorn/issues/840#issuecomment -482491267

안녕하세요 @benoitc입니다. 나는 이전 게시물에서 언급 한 바와 같이, 우리는 내가 이해, Gunicorn 동기화 "웹"의 사용을 제안, 파이썬 / 플라스크 서버 측 응용 프로그램 배포에 대한 관리에게 Heroku의 지침 (와 다음, Heroku가에 아주 간단 플라스크 / FlaskRestPlus 응용 프로그램을 배포 한 노동자 ).

앱의 동작은 이 스레드의 제목을 반영합니다.

로컬에서 테스트한 결과 모든 것이 잘 작동하며 앱은 문제 없이 20k 이상의 JSON을 제공합니다. 그러나 앱이 Heroku에 배포되면 503 오류 문제가 체계적으로 발생합니다. 말 그대로 트래픽이 없어도 출력이 전달되지 않습니다.
다른 사람들이 지적했듯이 로그는 HTTP 수준에서 모든 것이 정상인 것처럼 보입니다(200개의 응답 코드가 기록됨).
페이로드가 13k 미만이면 Heroku/Gunicorn이 예상대로 POST에 응답합니다.
우리는 POST(?!?) 끝점을 피하고 대신 GET을 사용한다는 @mikkelhn 아이디어를 따랐고 이것은 문제를 해결하는 (별로 좋지 않은) 방법인 것 같습니다.

우리는 Gunicorn 전문가가 아니며 솔직히 우리의 간단한 사용 사례가 "즉시" 작동할 것이라고 기대했습니다.
저희에게 도움이 될 제안이 있으시면 영원히 감사하겠습니다. :)

@RinaldoNani Shot in the dark... 요청 처리기 어딘가에서 request.data 모두 읽어보십시오. 예를 들어:

@route('/whatever', methods=['POST'])
def whatever_handler():
    str(request.data)
    return flask.jsonify(...)

그것이 당신의 오류에 영향을 줍니까?

저는 지금 2주 넘게 H18 문제로 분주한 후 오전 1시에 이것을 쓰고 있습니다(공유하기를 기다릴 수 없었습니다).

나는 거대한 데이터 세트로 작업하고 플롯에 18K에서 20K 레코드에 응답합니다. H18은 매우 임의의 오류로 발생했습니다. 때때로 잘 작동하지만 모든 브라우저에서 "콘텐츠 헤더 길이가 일치하지 않습니다"가 발생합니다. 이 문제에 대해 논의된 거의 모든 솔루션을 시도했지만 운이 없었습니다. 내가 시도한 두 가지가 마침내 작동했습니다.

1. POST 요청을 GET으로 변경했습니다.
2. 내 데이터에 NaN/Null 값이 있으므로 모델을 변경하고 기본값을 제공했습니다. (나는 이것이 문제를 해결했다고 생각한다)
   그 후, 나는이 오류가 발생하는 것을 멈췄습니다.
   이것이 누군가를 도울 수 있기를 바랍니다!