<p>gunicorn 19.x django-1.7.1 और gevent . के साथ समस्या पैदा कर रहा है</p>

पहले बस एक प्रश्न: क्या प्रीलोड विकल्प को निकालने से मदद मिलती है?
मुझे लगता है कि मुझे याद है कि इसी तरह का एक और मुद्दा बताया जा रहा है।
यदि उस विकल्प को बदलने से मदद मिलती है, तो हमने इस बारे में कुछ बदल दिया होगा कि Django एप्लिकेशन कैसे लोड किए जाते हैं और हमारे लिए इसे ट्रैक करना आसान होगा।

मैं _थिंक_ हम मास्टर प्रक्रिया में django wsgi एप्लिकेशन आयात करते हैं, जो कम से कम django 1.7 पर, आयात पर सभी django मॉडल प्रारंभ करता है।

नमस्ते @tilgovi , आपके समय के लिए धन्यवाद। मैं पुष्टि नहीं कर सकता कि preload_app = False का उपयोग करके मैं gunicorn-19.1.1 और django-1.7.1 का उपयोग करने में सक्षम हूं।

क्या आपको पता है कि 19.x संस्करणों में गनिकोर्न क्लाउड इसके बारे में अलग तरीके से क्या कर रहा है?

मुझे अब दूसरी समस्या है। मैं अपने django ऐप में रेवेन [1] का उपयोग करता हूं। और रेवेन दस्तावेज़ों के अनुसार, डब्लूएसजीयू मिडलवेयर [1] का उपयोग करते समय रेवेन को डब्लूएसजीआई ऑब्जेक्ट (मूल डीजेंगो डब्लूएसजीआई ऐप को लपेटकर) के रूप में उपयोग करना संभव है, और गनिकोर्न का उपयोग करते समय (बाहरी कमांड के रूप में, run_gunicorn django कमांड) हमें गनिकोर्न में एक हुक जोड़ना होगा[2]। जब यह हुक सक्षम होता है, तो गनिकोर्न केवल तभी बूट होता है जब preload_app = True , लेकिन तब gevent काम नहीं करता है। जब मैं हुक सक्षम के साथ preload_app = True उपयोग करता हूं, तो गनिकोर्न बूट भी नहीं करता है, मुझे और ImportError यह कहते हुए कि यह मेरे "DJANGO_SETTINGS_MODULE" को आयात नहीं कर सकता है।

रेवेन 4.2.3

अभी के लिए मैं वापस गनिकोर्न पर जाऊँगा 18.x , क्योंकि यह दोनों विन्यासों के साथ काम करता है (WSGI मिडलवेयर के रूप में gevent और raven)
क्या मुझे इसके बारे में एक और मुद्दा खोलना चाहिए?

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

@daltonmatos जिस तरह से django 1.7.1 में डेटाबेस सेटअप किया गया है, वह शायद बदल गया है, जाहिर तौर पर

एक और बात आज ही पता चली,
django 1.7 में गनिकोर्न 19.3.0 के साथ सत्र संचालन सेकंड के भीतर समाप्त हो जाता है।

इसे काम करने के लिए वापस 18 पर स्विच करना पड़ा।

एफवाईआई।

ऐसा लगता है कि यह https://github.com/benoitc/gunicorn/issues/879 जैसा ही मुद्दा है, जिसे बंद कर दिया गया था लेकिन ठीक नहीं किया गया था। यह गनिकोर्न 19.x बनाता है। Django के साथ अनुपयोगी। शायद केवल गेवेंट वर्कर के लिए? मैंने अन्य कार्यकर्ता प्रकारों के लिए परीक्षण नहीं किया है।

@tilgovi मुझे आश्चर्य है कि क्या यह पर्यावरण में किए गए बदलाव के कारण नहीं है। 19.x में हमने wsgi.multithread को true जहां यह 18.x में false था:

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

इस परिवर्तन को django में अलग तरह से नियंत्रित किया जा सकता है। और एक ग्रीनलेट वास्तव में एक धागा नहीं है। विचार? कम से कम शायद हम इसे वापस करने की कोशिश कर सकते हैं और जांच सकते हैं कि क्या यह समस्या हल करता है। क्या हमारे पास इस मुद्दे के लिए कोई परीक्षण या प्रतिलिपि प्रस्तुत करने योग्य तरीका है?

ओह, मुझे यकीन है कि यह मुद्दा है। अच्छी याददाश्त, @benoitc।

मुझे अभी भी पता नहीं क्यों। जैसा कि मैंने उस समय परिवर्तन को सही ठहराने के लिए कहा था, मैं कल्पना नहीं कर सकता कि यह कुछ भी तोड़ देगा क्योंकि इसका मतलब यह होगा कि ढांचा केवल डेटा साझा करने के बारे में अधिक सावधानी बरतेगा। जाहिर है, मैं गलत हो सकता हूं।

मैंने यह जांचने के लिए शाखा fix/927 को धक्का दिया कि उपरोक्त फिक्स काम करता है या नहीं। कृपया परीक्षण करें!

मैं अभी भी django 1.8.1 (और 1.7.1) और gevent 1.0.1 के साथ फिक्स/927 का उपयोग करके इस त्रुटि को पुन: उत्पन्न करने में सक्षम हूं

यह मेरे लिए आश्वस्त करने वाला है, भले ही हम अभी भी इसका कारण नहीं जानते हों।

इसलिए मैंने उदाहरण एप्लिकेशन का उपयोग करने का प्रयास किया और निम्न कमांड लाइन चलाने वाली समस्या को पुन: उत्पन्न नहीं किया:

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

क्या कोई मुझे एक प्रतिलिपि प्रस्तुत करने योग्य उदाहरण प्रदान कर सकता है?

मैं अभी भी इस मुद्दे को पुन: पेश कर सकता हूं जैसे कि गनिकोर्न का आह्वान करना:

    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

ऐसा हो रहा है, 1in 10/15 अनुरोध एक मॉडल पर गिनती कर रहे हैं। मुझे संदेह है कि यह मेरे आवेदन में एक त्रुटि है जो अब खुला है।

@ ब्रोकहेवुड कूल! बीटीडब्ल्यू अहाट जीवेंट का आपका संस्करण है? आपकी नवीनतम त्रुटि के लिए यह वास्तव में गनिकोर्न से संबंधित नहीं लगता है।

याह, अच्छी खबर! gevent के संस्करण 1.0.1 पर।

@tilgovi तो मुझे आश्चर्य है कि क्या हमें थ्रेड बंदर पैचिंग को हटाकर गनिकोर्न को पैच नहीं करना चाहिए। शायद हमें भी सेट करना चाहिए wsgi.multithread से False ? विचार?

@benoitc मैं उस नई त्रुटि को पुन: उत्पन्न करने में सक्षम हूं जिसे मैंने ऊपर एक बहुत ही सरल Django एप्लिकेशन के साथ संदर्भित किया है जिसमें केवल एक दृश्य है और एक साधारण मॉडल क्वेरी करता है और यदि मैं एकाधिक समवर्ती अनुरोध चलाता हूं तो गिनती करता हूं।

क्या आपके पास कोई सुझाव है कि कौन सा घटक सबसे अधिक संभावित अपराधी है? क्या यह संभावित रूप से एक गीवेंट समस्या या साइकोग्रीन है?

अधिक संभावना साइकोग्रीन। क्या आप इसे सेटअप करने के लिए ऐसे हुक का उपयोग कर रहे हैं?

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

मैं आपके सुझाव का प्रयास करूंगा।

यदि मैं साइकोग्रीन का कोड पढ़ता हूं तो आपका कोड अधिक सटीक है:

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

ठीक है, मैं साइकोग्रीन के साथ टिकट खोलने की कोशिश करती हूँ

आप हुक इस्तेमाल करने की कोशिश कर सकते हैं post_worker_init के बजाय post_fork ?

पोस्ट_वर्कर_इनिट में साइकोग्रीन को पैच करते समय अभी भी मेरे लिए होता है।

मैंने साइकोग्रीन को भी टिकट जमा किया है:
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

धन्यवाद!

रविवार, मई १७, २०१५ अपराह्न १०:३४ बजे ब्रोकहेवुड नोटिफिकेशन @github.com
लिखा था:

यहां सरल परियोजना जिसे मैं पुन: पेश करने के लिए उपयोग कर रहा हूं:
https://github.com/brockhaywood/gunicorn_gevent_issue

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/927#issuecomment -102852497।

@benoitc इस पर कोई विचार?

@brockhaywood क्षमा करें मेरे पास इसका परीक्षण करने का समय नहीं था। चूँकि मैं कल एक उड़ान में बंद हूँ, मैं वैसे भी करूँगा :)

धन्यवाद
२६ मई २०१५ को दोपहर १:१७ बजे, "बेनोइट चेसन्यू" नोटिफिकेशन @github.com ने लिखा:

@brockhaywood https://github.com/brockhaywood क्षमा करें मेरे पास समय नहीं था
इसका परीक्षण करने के लिए। चूँकि मैं कल एक उड़ान में बंद हूँ, मैं वैसे भी करूँगा :)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/benoitc/gunicorn/issues/927#issuecomment -105652947।

जब मैंने यह धागा देखा तो बस उसी डेटाबेसवापर समस्या का सामना कर रहा था।

मैं पुष्टि कर सकता हूं कि मेरी gunicorn कॉन्फ़िगरेशन फ़ाइल से preload_app विकल्प को हटाने से समस्या ठीक हो जाती है। मैं उपयोग कर रहा हूँ:

• Django == 1.7.7
• गीवेंट == 1.0.2
• गनिकोर्न==19.3.0
• psycopg2==2.5.2
• साइकोग्रीन == 1.0
• Gunicorn PgBouncer द्वारा लपेटा गया

(जब से हम इस धागे में वर्णित समान मुद्दों को देख रहे हैं, तब से कूदते हुए)

ऐसा लगता है कि ये समस्याएँ #478 समस्या को ठीक करने के कारण हो रही हैं (मास्टर को मंकी पैच न करें)।

यदि आप गीवेंट वर्कर्स का उपयोग कर रहे हैं, तो बंदर द्वारा मास्टर को पैच न करने से, ऐप प्रीलोड मूल रूप से एक बेमेल पैदा करता है। प्रीलोड के हिस्से के रूप में चलने वाला कोई भी ऐप कोड ऐसे वातावरण में चलता है जो बंदर पैच नहीं है। कोई भी ऐप कोड जो वर्कर में चलता है वह मंकी पैच वाले वातावरण में चलता है।

हमारे लिए, बस setup पद्धति को gevent कार्यकर्ता वर्ग में पुनर्स्थापित करना जैसा कि इसे 18.x में परिभाषित किया गया है, ताकि मास्टर बंदर पैच किया गया हो और यह ऐप प्रीलोड से पहले बंदर पैच किया गया हो, सभी को ठीक किया गया हमारे मुद्दे। इसमें DatabaseWrapper बग शामिल है, साथ ही एक अन्य मुद्दा जो हम देख रहे थे कि gevent कार्यकर्ता कहां लटकेंगे और टाइमआउट करेंगे। कोई अन्य परिवर्तन आवश्यक नहीं थे (उदाहरण के लिए, हमें मंकी पैचिंग threads को अक्षम करने की आवश्यकता नहीं है)।

मैं अभी भी मास्टर प्रक्रिया को बंदर-पैच करने में बहुत संकोच करूंगा, लेकिन यदि आप इसे करना चाहते हैं तो आप गनिकोर्न को पैच करने के बजाय सर्वर हुक का उपयोग करने में सक्षम हो सकते हैं। यदि आप ऐसा कर सकते हैं, तो मैं किसी भी तरह से इसका स्वागत करता हूं कि हम इसे कहीं बेहतर तरीके से दस्तावेज कर सकते हैं।

मुझे लगता है कि हमारे लिए अल्पकालिक योजना इस पैच के साथ एक (आंतरिक) गनिकोर्न कांटा बनाने की है।

मैं अपने wsgi कोड में एक बंदर पैच चरण को स्थानांतरित करने की जांच करूंगा, लेकिन यह अभी भी कुछ ऐसा लगता है जो गनिकोर्न कोड के अंदर किया जाना चाहिए (यहां तक ​​​​कि एक विन्यास योग्य विकल्प के रूप में)। प्रीलोडेड ऐप कोड में पैचिंग मास्टर को एक तरह से या किसी अन्य को प्रभावित करेगा, और पूरी बात यह होगी कि मास्टर के साथ कर्मचारियों की बंदर की स्थिति को बनाए रखा जाए। ऐप कोड में मास्टर मंकी पैच को लागू करने का मतलब है कि ऐप डेवलपर्स जो इस व्यवहार पर निर्भर हैं, वे हमेशा उन सभी परिवर्तनों के लिए कैचअप खेलेंगे जो गनिकोर्न करता है कि कब/कैसे यह बंदर कार्यकर्ता को पैच करता है।

यदि यह जल्दी पैच करने का काम करता है, तो शायद इसे एक बदलाव के रूप में माना जाना चाहिए।

मुझे याद नहीं है कि क्या कभी ऐसा हुआ था और अगर इससे समस्याएं हुईं, लेकिन बंदर पैचिंग के साथ यह हमेशा मुश्किल होता है।

हमारे अपने उत्पादन गनिकोर्न एप्लिकेशन को प्रीलोडिंग की आवश्यकता होती है (हम ऐप लॉन्च करने के लिए पिरामिड/पेस्ट की pserve स्क्रिप्ट का उपयोग करते हैं और एक आईएनआई फ़ाइल से गनिकोर्न लोड करते हैं; हमारे पास इसके चारों ओर एक रैपर है सुनिश्चित करें कि बंदर-पैचिंग ASAP होता है)।

मैं एक वर्तमान gevent अनुचर हूँ। इस परिदृश्य को बेहतर ढंग से काम करने के लिए आवश्यक किसी भी मुद्दे को देखकर मुझे खुशी हो रही है। हम जल्द ही 1.1 छोड़ने की उम्मीद कर रहे हैं और यह बहुत अच्छा होगा यदि यह एक समर्थित विकल्प था।

मैंने अपने wsgi कार्यान्वयन के शीर्ष पर एक ही बंदर पैच तर्क को लागू करने का प्रयास किया, और हमने DatabaseWrapper मुद्दा देखना शुरू कर दिया। पूरी तरह से निश्चित नहीं है कि क्यों - arbiter.py में wsgi आमंत्रण को देखते हुए , उस बिंदु के बाद कुछ पंक्तियां होती हैं जहां GeventWorker.setup को कॉल किया जाएगा ( worker_class असाइनमेंट के साइड इफेक्ट के रूप में। अगर मैं पढ़ रहा हूं कोड सही।

अगर मेरे पास यूरेका है या ऐप कोड के संबंध में भाग्यशाली है, तो मैं फॉलोअप करूंगा, लेकिन अभी तक हमारे लिए, गनिकोर्न मास्टर कोड में पहले पैच करना ही एकमात्र फिक्स है जो हमारे सभी मुद्दों को हल करता है।

@jamadden बहुत बहुत धन्यवाद।

@jzupko यह आमतौर पर महत्वपूर्ण है कि पैचिंग किसी भी आयात से पहले होती है जो प्रभावित हो सकती है। इसलिए मैंने इसे सर्वर हुक में करने का सुझाव दिया, जैसे post_fork फ़ंक्शन को gunicorn.conf.py फ़ाइल में डालकर। हालांकि, मुझे अभी एहसास हुआ कि किसी भी सर्वर हुक से पहले एप्लिकेशन प्रीलोडिंग होता है और यह स्पष्ट नहीं है कि कोई ऐसा कहां करेगा।

@benoitc क्या हमारे पास कार्यकर्ता-विशिष्ट कॉन्फ़िगरेशन के लिए कोई तंत्र है?

मैं इसे रिलीज 20 मील के पत्थर में जोड़ रहा हूं और सुझाव दे रहा हूं कि हम बंदर को मास्टर को पैच करने पर विचार करें, हो सकता है, अगर यह # 478 जैसी समस्याओं को फिर से पेश किए बिना किया जा सकता है।

@tilgovi आपके पास कार्यकर्ता की setup विधि है जिसका उपयोग मेरे विचार से किया जा सकता है।

क्या किसी के पास इसके लिए अस्थायी सुधार है जब तक कि 20.0 बाहर न हो जाए? या preload_app को अक्षम करने या 18.0 पर डाउनग्रेड करने के बीच चयन करने का एकमात्र समाधान है?

@fletom अस्थायी फिक्स के लिए? क्या आपने नवीनतम मास्टर की कोशिश की? क्या यह आपके लिए काम करता है?

@benoitc मेरा मतलब है "

वर्तमान गनिकोर्न मास्टर वास्तव में मेरे लिए बिल्कुल भी काम नहीं करता है। नियमित रूप से 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 आप

@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 ने गनिकोर्न के मंकी-पैचिंग से पहले कनेक्शन शुरू किया।

@gukoff प्रस्तावित फिक्स मेरे लिए काम नहीं करता है, मुझे अभी भी वही त्रुटि मिलती है

मैं इसे बंद करने जा रहा हूं और आर 20 मील के पत्थर पर मेलिंग सूची लेबल के साथ एक चर्चा खोलने जा रहा हूं ताकि गीवेंट में आर्बिटर को बंदर-पैचिंग किया जा सके। यदि आपको इस चर्चा में किसी भी चीज़ से संबंधित समस्या हो रही है और आपको लगता है कि यह Gunicorn में एक बग हो सकता है, तो कृपया एक मुद्दा खोलें। यदि आप संदर्भ जोड़ने में मदद करते हैं, तो आप संख्या के आधार पर या टिप्पणियों के लिंक का उल्लेख कर सकते हैं, लेकिन इस बिंदु पर यह एक पुराना टिकट है जिसमें गनिकोर्न के कई संस्करणों और विभिन्न लक्षणों के समानांतर बातचीत है।