<p>django-1.7.1 및 gevent에 문제를 일으키는 gunicorn 19.x</p>

먼저 질문만 하십시오. 사전 로드 옵션을 사용하는 것이 도움이 됩니까?
다른 유사한 문제가 보고된 것으로 기억합니다.
해당 옵션을 변경하는 것이 도움이 된다면 Django 애플리케이션이 로드되는 방식을 변경해야 하고 추적하기가 더 쉬울 것입니다.

나는 적어도 django 1.7에서는 가져올 때 모든 django 모델을 초기화하는 마스터 프로세스에서 django wsgi 애플리케이션을 _생각_합니다.

안녕하세요 @tilgovi , 시간 내주셔서 감사합니다. preload_app = False 를 사용하여 gunicorn-19.1.1 및 django-1.7.1 를 사용할 수 있는지 확인할 수 없습니다.

19.x 버전에서 이에 대해 gunicorn 클라우드가 어떻게 다른지 알고 있습니까?

이제 두 번째 문제가 있습니다. 내 django 앱에서 Raven[1]을 사용합니다. 그리고 Raven 문서에 따르면 WSGU 미들웨어[1]를 사용할 때 Raven을 WSGI 객체로 사용할 수 있고(원래 django WSGI 앱 래핑) gunicorn을 사용할 때( run_gunicorn 아닌 외부 명령으로) preload_app = True 인 경우에만 부팅되지만 gevent는 작동하지 않습니다. 내가 사용하는 경우 preload_app = True 후크 활성화와 함께, gunicorn도 부팅, 저를 포기하지 않고 ImportError 내 "DJANGO_SETTINGS_MODULE"을 가져올 수 없다는.

까마귀는 4.2.3

지금은 gunicorn 18.x 돌아가겠습니다. 두 구성(WSGI 미들웨어로 gevent 및 raven)에서 작동하기 때문입니다.
이에 대해 다른 문제를 열어야 합니까?

[1] http://raven.readthedocs.org/en/latest/config/django.html#wsgi -middleware
[2] http://raven.readthedocs.org/en/latest/config/django.html#gunicorn

@daltonmatos django 1.7.1에서 데이터베이스가 설정되는 방식은 아마도 스레드로부터 안전하지 않은 것으로 변경되었을 것입니다. 그 시점에서 무엇을 해야 할지 잘 모르겠습니다.

또 하나 오늘 알게 된 사실,
gunicorn 19.3.0이 포함된 django 1.7의 세션 처리가 몇 초 안에 만료됩니다.

작동하려면 18로 다시 전환해야 했습니다.

참고로

이것은 폐쇄되었지만 수정되지 않은 https://github.com/benoitc/gunicorn/issues/879 와 동일한 문제인 것 같습니다. 그것은 gunicorn 19.x를 만듭니다. Django에서는 사용할 수 없습니다. 아마도 gevent 작업자에게만 해당됩니까? 다른 작업자 유형에 대해서는 테스트하지 않았습니다.

@tilgovi 환경에서 수행된 변경으로 인한 것이 wsgi.multithread 를 true 로 설정했으며 18.x에서는 false 였습니다.

https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/ggevent.py#L99

이 변경은 django에서 다르게 처리될 수 있습니다. 그리고 greenlet은 실제로 스레드가 아닙니다. 생각? 적어도 되돌리고 문제가 해결되는지 확인할 수는 있습니다. 이 문제에 대한 테스트 또는 재현 가능한 방법이 있습니까?

아, 그게 문제인 것 같아요. 좋은 기억, @benoitc.

아직까지는 이유를 모르겠습니다. 변경을 정당화하기 위해 당시에 말했듯이 프레임워크가 데이터 공유에 대해 더 많은 예방 조치를 취한다는 것을 의미하기 때문에 아무 것도 중단할 것이라고 상상할 수 없습니다. 분명히, 내가 틀릴 수 있습니다.

위의 수정 사항이 작동하는지 확인하기 위해 분기 fix/927 를 푸시했습니다. 테스트 해주세요!

나는 여전히 django 1.8.1(및 1.7.1) 및 gevent 1.0.1에서 fix/927을 사용하여 이 오류를 재현할 수 있습니다.

아직 원인을 알지 못하더라도 안심이 됩니다.

그래서 예제 애플리케이션을 사용해 보았지만 다음 명령줄을 실행하는 문제를 재현하지 못했습니다.

gunicorn --env DJANGO_SETTINGS_MODULE=testing.settings -k gevent -w3 wsgi:application

누구든지 나에게 재현 가능한 예를 제공할 수 있습니까?

나는 여전히 다음과 같이 gunicorn을 호출하는 이 문제를 재현할 수 있습니다.

    gunicorn --env DJANGO_SETTINGS_MODULE=settings -w 3 --max-requests=1000 -b 0.0.0.0:8000 -k gevent --config ogs/gunicorn.py  --pythonpath ogs wsgi:application

필요한 관련 세부 정보가 있습니까?

@brockhaywood 는 project.settings 이어야 하지만 재현할 방법이 필요합니다. 공유할 최소한의 코드가 있습니까?

위의 흔적을 보면 원숭이 패치일 수도 있습니다. 어쩌면 스레드는 원숭이 패치되어서는 안됩니다. 다음 패치를 시도해 볼 수 있습니까?

--- a/gunicorn/workers/ggevent.py
+++ b/gunicorn/workers/ggevent.py
@@ -60,9 +60,9 @@ class GeventWorker(AsyncWorker):

         # if the new version is used make sure to patch subprocess
         if gevent.version_info[0] == 0:
-            monkey.patch_all()
+            monkey.patch_all(thread=False)
         else:
-            monkey.patch_all(subprocess=True)
+            monkey.patch_all(subprocess=True, thread=False)

         # monkey patch sendfile to make it none blocking
         patch_sendfile()

다음 wsgi와 함께 위의 패치를 사용하면 더 이상 지정된 오류가 생성되지 않습니다.

import os

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings")

from gevent import monkey
monkey.patch_all(thread=False)

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

from django.core.cache.backends.memcached import BaseMemcachedCache
BaseMemcachedCache.close = lambda self, **kwargs: None

이제 다른 새로운 오류가 표시되지만 관련되어 있는지 전혀 모릅니다.

ProgrammingError: close cannot be used while an asynchronous query is underway

이는 10/15 요청 중 1건이 모델에서 계산을 수행하는 중입니다. 나는 이것이 지금 밝혀진 내 응용 프로그램의 오류라고 생각합니다.

@brockhaywood 멋지다! btw ahat 당신의 gevent 버전입니까? 최신 오류의 경우 실제로 gunicorn과 관련이 없는 것 같습니다.

좋은 소식입니다! gevent 버전 1.0.1에서.

@tilgovi 그래서 스레드 원숭이 패치를 제거하는 gunicorn을 패치해서는 안되는지 궁금합니다. wsgi.multithread 도 False 해야 할까요? 생각?

@benoitc 보기가 하나만 있고 여러 동시 요청을 실행하는 경우 간단한 모델 쿼리 및 계산을 수행하는 매우 간단한 Django 애플리케이션으로 위에서 참조한 새로운 오류를 재현할 수 있습니다.

가장 가능성이 높은 구성 요소에 대한 제안 사항이 있습니까? 이것은 gevent 문제 또는 psycogreen 가능성이 있습니까?

사이코그린일 가능성이 더 큽니다. 그런 후크를 사용하여 설정합니까?

def def_post_fork(server, worker):
    from psycogreen.gevent import psyco_gevent
    psyco_gevent.make_psycopg_green()
    worker.log.info("Made Psycopg Green")

아, 실제로 사용하고 있는

def post_fork(server, worker):    
    from psycogreen.gevent import patch_psycopg
    patch_psycopg()

당신의 제안을 시도하겠습니다.

psycogreen의 코드를 읽으면 코드가 더 정확합니다.

https://bitbucket.org/dvarrazzo/psycogreen/src/115d0627da1ac9ff48c0cb9287257cd35868cdf9/psycogreen/gevent.py?at=master#cl -17

좋아, 싸이코그린으로 티켓을 열어볼게

당신은 후크를 사용하려고 할 수 있습니다 post_worker_init 대신 post_fork ?

post_worker_init에서 psycogreen을 패치할 때 여전히 발생합니다.

싸이코그린에도 티켓을 제출했습니다.
https://bitbucket.org/dvarrazzo/psycogreen/issue/2/databaseerror-used-with-asynchronous-query

@brockhaywood OK:/ 이 링크도 찾았습니다: https://bitbucket.org/dvarrazzo/psycogreen-hg/issue/1/databaseerror-execute-used-with . 그래도 도움이 될 수 있을지 모르겠습니다.

나는 그것을 살펴 보았고 동일한 문제처럼 보이지만 불행히도 해결 방법을 보지 못했습니다.

@brockhaywood 문제를 재현하는 데 도움이 될 수 있는 간단한 코드 예를 공유할 수 있습니까? 내일 봐야겠다.

다음은 재현하는 데 사용하는 간단한 프로젝트입니다.
https://github.com/brockhaywood/gunicorn_gevent_issue

감사 해요!

2015년 5월 17일 일요일 오후 10:34 brockhaywood [email protected]
썼다:

다음은 재현하는 데 사용하는 간단한 프로젝트입니다.
https://github.com/brockhaywood/gunicorn_gevent_issue

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/927#issuecomment -102852497.

@benoitc 이에 대한 생각이 있습니까?

@brockhaywood 테스트할 시간이

감사 해요
2015년 5월 26일 오후 1시 17분에 "Benoit Chesneau" [email protected]에 다음과 같이 썼습니다.

@brockhaywood https://github.com/brockhaywood 시간이 없어서 죄송합니다
그것을 테스트합니다. 내일 비행기에 묶여 있기 때문에 어쨌든 갈 것입니다 :)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/benoitc/gunicorn/issues/927#issuecomment -105652947.

이 스레드를 보았을 때 동일한 DatabaseWrapper 문제가 발생했습니다.

내 gunicorn 구성 파일에서 preload_app 옵션을 제거하면 문제가 해결된다는 것을 확인할 수 있습니다. 나는 사용하고있다 :

• 장고==1.7.7
• gevent==1.0.2
• gunicorn==19.3.0
• 사이코프2==2.5.2
• 사이코그린==1.0
• PgBouncer에 의해 감싸인 gunicorn

(이 스레드에서 설명한 것과 동일한 문제를 보고 있었기 때문에 뛰어들었습니다.)

이러한 문제는 문제 #478 (원숭이 패치를 마스터하지 않음)에 대한 수정 으로 인해 발생한 것 같습니다.

원숭이가 마스터를 패치하지 않음으로써 gevent 작업자를 사용하는 경우 앱 사전 로드는 근본적으로 불일치를 생성합니다. 사전 로드의 일부로 실행되는 모든 앱 코드는 원숭이 패치가 적용되지 않은 환경에서 실행됩니다. 작업자에서 실행되는 모든 앱 코드는 원숭이 패치 환경에서 실행됩니다.

우리의 경우 setup 메소드를 gevent 작업자 클래스로 복원하기 setup 하면 18.x에 정의된 대로 마스터가 원숭이 패치되고 앱 사전 로드 이전에 원숭이 패치됩니다. 우리의 문제. 여기에는 DatabaseWrapper 버그와 gevent 작업자가 멈추고 시간 초과되는 또 다른 문제가 포함됩니다. 다른 변경은 필요하지 않았습니다(예를 들어, 원숭이 패치 threads 를 비활성화할 필요가 없습니다).

나는 여전히 마스터 프로세스를 원숭이 패치하는 것을 매우 주저하겠지만, 만약 당신이 그것을 하고 싶다면 gunicorn 자체를 패치하는 대신 서버 후크를 사용할 수 있을 것입니다. 그렇게 할 수 있다면 여기보다 더 나은 곳에서 문서화할 수 있는 방법을 환영합니다.

단기 계획은 이 패치가 적용된 (내부) gunicorn 포크를 만드는 것입니다.

나는 원숭이 패치 단계를 wsgi 코드로 옮기는 것을 조사할 것이지만, 이것은 여전히 ​​gunicorn 코드 내에서 수행되어야 하는 것처럼 보입니다(구성 가능한 옵션으로도). 사전 로드된 앱 코드의 패치는 마스터에 어떤 식으로든 영향을 미치며 요점은 작업자의 원숭이 패치 상태를 마스터와 동기화하도록 유지하는 것입니다. 앱 코드에 마스터 원숭이 패치를 적용한다는 것은 이 동작에 의존하는 앱 개발자가 원숭이가 작업자를 패치하는 시기/방법에 대해 gunicorn이 만드는 모든 변경 사항을 항상 따라잡는다는 것을 의미합니다.

패치가 일찍 작동한다면 아마도 변경 사항으로 간주되어야 할 것입니다.

그것이 사실인지, 그리고 그것이 문제를 일으켰는지 기억나지 않지만, 원숭이 패치에서는 항상 까다롭습니다.

우리 자신의 프로덕션 gunicorn 응용 프로그램 은 사전 로드 필요합니다 (우리는 Pyramid/paste의 pserve 스크립트를 사용하여 앱을 시작하고 ini 파일에서 gunicorn을 로드합니다. 원숭이 패치가 최대한 빨리 발생하는지 확인).

저는 현재 gevent 관리자입니다. 이 시나리오가 더 잘 작동하도록 하는 데 필요한 gevent의 모든 문제를 살펴보게 되어 기쁩니다. 우리는 곧 1.1을 드롭할 것으로 예상하며 이것이 지원되는 옵션이라면 좋을 것입니다.

나는 wsgi 구현의 맨 위에 동일한 원숭이 패치 논리를 적용하려고 시도했고 DatabaseWrapper 문제를 보기 시작했습니다. 이유는 확실하지 않지만 - arbiter.py 에서 wsgi 호출을 보면 GeventWorker.setup 가 호출되는 지점 몇 줄 뒤에 발생합니다( worker_class 할당 의

유레카가 있거나 앱 코드와 관련하여 운이 좋으면 후속 조치를 취하겠습니다. 그러나 지금까지는 gunicorn 마스터 코드에서 더 일찍 패치하는 것이 모든 문제를 해결하는 유일한 수정 사항입니다.

@jamadden 정말 감사합니다.

@jzupko 일반적으로 영향을 받을 수 있는 가져오기 전에 패치가 발생하는 것이 중요합니다. 그래서 gunicorn.conf.py 파일에 post_fork 함수를 넣는 것과 같이 서버 후크에서 수행할 것을 제안했습니다. 그러나 응용 프로그램 사전 로드가 서버 후크보다 먼저 발생하고 어디에서 수행할지 명확하지 않다는 것을 방금 깨달았습니다.

@benoitc 작업자별 구성을 위한 메커니즘이 있습니까?

나는 이것을 릴리스 20 이정표에 추가하고 #478과 같은 문제를 다시 도입하지 않고 수행할 수 있다면 원숭이가 마스터를 패치하는 것을 고려할 것을 제안합니다.

@tilgovi 는 작업자의 setup 메소드를 사용할 수 있다고 생각합니다.

20.0이 나올 때까지 임시로 수정한 사람이 있습니까? 아니면 preload_app 비활성화 또는 18.0으로 다운그레이드 중에서 선택할 수 있는 유일한 솔루션입니까?

@fletom 임시 수정 사항? 최신 마스터를 사용해 보셨습니까? 그것은 당신을 위해 작동 했습니까?

@benoitc "DatabaseWrapper objects" 오류에 대한 수정을 의미합니다.

현재 gunicorn 마스터는 실제로 전혀 작동하지 않습니다. 일반 19.6.0에서 나는 이것을 얻습니다 (정상).

[2017-01-05 15:46:32 -0500] [3222] [INFO] Starting gunicorn 19.6.0
[2017-01-05 15:46:32 -0500] [3222] [INFO] Listening at: http://127.0.0.1:8000 (3222)
[2017-01-05 15:46:32 -0500] [3222] [INFO] Using worker: gevent
[2017-01-05 15:46:32 -0500] [3226] [INFO] Booting worker with pid: 3226
[2017-01-05 15:46:32 -0500] [3227] [INFO] Booting worker with pid: 3227
[2017-01-05 15:46:32 -0500] [3228] [INFO] Booting worker with pid: 3228
[2017-01-05 15:46:32 -0500] [3229] [INFO] Booting worker with pid: 3229

그리고 100% 정확히 동일한 구성을 가진 최신 마스터에서 나는 이것을 얻었고 내가 말할 수 있는 한 어떤 포트에서도 수신하지 않습니다.

[2017-01-05 15:47:19 -0500] [3308] [INFO] Starting gunicorn 19.6.0
[2017-01-05 15:47:19 -0500] [3308] [INFO] Listening at:  (3308)
[2017-01-05 15:47:19 -0500] [3308] [INFO] Using worker: gevent
[2017-01-05 15:47:19 -0500] [3312] [INFO] Booting worker with pid: 3312
[2017-01-05 15:47:19 -0500] [3313] [INFO] Booting worker with pid: 3313
[2017-01-05 15:47:19 -0500] [3314] [INFO] Booting worker with pid: 3314
[2017-01-05 15:47:19 -0500] [3315] [INFO] Booting worker with pid: 3315

도청된 것 같습니까?

@fletom gunicorn을 어떻게 시작합니까?

@benoitc 이 경우 gunicorn -c gunicorn_conf.py <appname>.wsgi 입니다.

내 gunicorn_conf.py :

workers = 4

worker_class = 'gevent'

preload_app = False

gunicorn==18.0 이 문제에 걸려 넘어졌습니다. gunicorn_conf.py에는 worker_class = 'gevent' , preload_app = True 및 사용자 정의 pre_fork , on_starting 및 on_reload 함수가 있습니다.

gunicorn_conf.py 파일 위에 다음 줄을 추가하면 문제가 해결되는 것 같습니다.

import gevent.monkey
gevent.monkey.patch_thread()

업데이트:
내 gunicorn.conf에 이러한 줄이 있습니다. 그것들을 제거하면 원숭이 패치 없이 문제가 해결되었습니다.

import django
django.setup()

그들 때문에 django는 gunicorn의 원숭이 패치 전에 연결을 시작했습니다.

@gukoff가 제안한 수정 사항이 효과가 없었지만 여전히 동일한 오류가 발생합니다 😞

나는 이것을 닫고 gevent에서 중재자를 원숭이 패치하기 위한 R20 이정표의 메일링 리스트 레이블과 토론을 열 것입니다. 이 토론과 관련된 문제가 있고 Gunicorn의 버그일 수 있다고 생각되면 문제를 여십시오. 맥락을 추가하는 데 도움이 된다면 이것을 번호로 언급하거나 댓글에 링크할 수 있습니다. 그러나 이 시점에서 이것은 여러 버전의 Gunicorn 및 다양한 증상에 대한 대화가 있는 오래된 티켓입니다.