<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 .

هل لديك أي فكرة عما تفعله سحابة gunicorn بشكل مختلف حول هذا الأمر في الإصدارات 19.x ؟

لدي الآن مشكلة ثانية. أستخدم Raven [1] في تطبيق django الخاص بي. وبالتوافق مع مستندات Raven ، عند استخدام برنامج وسيط WSGU [1] ، من الممكن استخدام Raven ككائن WSGI (التفاف تطبيق django WSGI الأصلي) ، وعند استخدام gunicorn (كأمر خارجي ، وليس run_gunicorn django command) يجب أن نضيف خطافًا إلى gunicorn [2]. عند تمكين هذا الخطاف ، يتم تشغيل gunicorn فقط إذا كان preload_app = True ، ولكن بعد ذلك لا يعمل gevent. عندما أستخدم preload_app = True مع تمكين الخطاف ، لا يقوم برنامج gunicorn بالتمهيد ، مما يمنحني و ImportError يقول إنه لا يمكنه استيراد "DJANGO_SETTINGS_MODULE" الخاص بي.

Raven هو 4.2.3

في الوقت الحالي ، سأعود إلى gunicorn 18.x ، لأنه يعمل مع كل من التكوينات (gevent و raven كبرنامج وسيط WSGI)
هل يجب أن أفتح عددًا آخر حول هذا الموضوع؟

[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 ربما تكون قد تغيرت على ما يبدو ليست Threadafe. لست متأكدًا مما يجب فعله في هذه المرحلة.

هناك شيء آخر ، اكتشفته للتو اليوم ،
تنتهي معالجة الجلسة في django 1.7 مع gunicorn 19.3.0 في غضون ثوانٍ.

اضطررت للعودة إلى 18 لإنجاحها.

لعلمك.

يبدو أن هذه هي نفس المشكلة مثل https://github.com/benoitc/gunicorn/issues/879 ، والتي تم إغلاقها ولكن لم يتم إصلاحها. يجعل من gunicorn 19.x. غير صالح للاستعمال مع Django. ربما فقط للعامل gevent بالرغم من ذلك؟ لم أختبر أنواع العمال الأخرى.

tilgovi أتساءل إذا لم يكن ذلك بسبب التغيير الذي حدث في البيئة. في 19.x قمنا بتعيين wsgi.multithread إلى true حيث كان false في 18.x:

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

قد يتم التعامل مع هذا التغيير بشكل مختلف في django. و Greenlet ليس في الحقيقة خيطًا. أفكار؟ على الأقل ربما يمكننا محاولة التراجع عنه والتحقق مما إذا كان يحل المشكلة. هل لدينا اختبار أو طريقة قابلة للتكرار لهذه المشكلة؟

أوه ، أراهن أن هذه هي القضية. ذاكرة جيدة ،benoitc.

ما زلت لا أعرف لماذا حتى الآن. كما قلت في ذلك الوقت لتبرير التغيير ، لا أستطيع أن أتخيل أنه سيؤدي إلى كسر أي شيء لأنه سيعني أن إطار العمل سيتخذ المزيد من الاحتياطات حول مشاركة البيانات. من الواضح أنني قد أكون مخطئا.

لقد دفعت الفرع fix/927 للتحقق مما إذا كان الإصلاح أعلاه يعمل. الرجاء الاختبار!

ما زلت قادرًا على إعادة إنتاج هذا الخطأ باستخدام fix / 927 مع django 1.8.1 (و 1.7.1) و gevent 1.0.1

هذا مطمئن بالنسبة لي ، حتى لو كنا ما زلنا لا نعرف السبب.

لذلك حاولت استخدام تطبيق المثال ولم أعد إنتاج المشكلة بتشغيل سطر الأوامر التالي:

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

يحدث هذا ، 1 في 10/15 طلب يقوم بحساب النموذج. أظن أن هذا خطأ في طلبي والذي تم اكتشافه الآن.

تضمين التغريدة راجع للشغل ما هي نسختك من gevent؟ بالنسبة لخطأك الأخير ، لا يبدو أنه مرتبط بجونيكورن بالفعل.

يا له من أخبار جيدة! في الإصدار 1.0.1 من gevent.

tilgovi لذا أتساءل عما إذا كان يجب علينا عدم تصحيح gunicorn إزالة ترقيع القرد الخيطي. ربما يجب علينا أيضًا تعيين wsgi.multithread إلى False ؟ أفكار؟

benoitc أنا قادر على إعادة إنتاج الخطأ الجديد الذي أشرت إليه أعلاه باستخدام تطبيق Django بسيط جدًا له طريقة عرض واحدة فقط ويقوم باستعلام نموذج بسيط ويعتمد إذا قمت بتشغيل عدة طلبات متزامنة.

هل لديك أي اقتراحات بشأن أي مكون هو الجاني الأكثر احتمالا؟ هل من المحتمل أن تكون هذه مشكلة جسيمة أو نفسية؟

على الأرجح 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

حسنًا ، سأحاول فتح تذكرة باستخدام psycogreen

هل يمكنك محاولة استخدام الخطاف post_worker_init بدلاً من post_fork ؟

لا يزال يحدث بالنسبة لي عند الترقيع psycogreen في post_worker_init.

لقد أرسلت تذكرة إلى psycogreen أيضًا:
https://bitbucket.org/dvarrazzo/psycogreen/issue/2/databaseerror-used-with-asynchronous-query

brockhaywood موافق: / وجدت أيضًا هذا الرابط: https://bitbucket.org/dvarrazzo/psycogreen-hg/issue/1/databaseerror-execute-used-with . لست متأكدًا مما إذا كان يمكن أن يساعدك على الرغم من ذلك.

لقد ألقيت نظرة على ذلك ويبدو أنه نفس المشكلة ولكني لم أر حلاً ، لسوء الحظ.

brockhaywood ، هل يمكنك مشاركة أي مثال بسيط على التعليمات البرمجية التي يمكن أن تساعدني في إعادة

هنا المشروع البسيط الذي أستخدمه لإعادة الإنتاج:
https://github.com/brockhaywood/gunicorn_gevent_issue

شكرا!

يوم الأحد 17 مايو 2015 الساعة 10:34 مساءً brockhaywood [email protected]
كتب:

هنا المشروع البسيط الذي أستخدمه لإعادة الإنتاج:
https://github.com/brockhaywood/gunicorn_gevent_issue

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/benoitc/gunicorn/issues/927#issuecomment -102852497.

benoitc أي أفكار حول هذا؟

brockhaywood آسف لم يكن لدي الوقت لاختباره. بما أنني محبوس في رحلة غدًا ، سأفعل على أي حال :)

شكرا
في 26 مايو 2015 الساعة 1:17 مساءً ، كتب "Benoit Chesneau" [email protected] :

brockhaywood https://github.com/brockhaywood آسف لم يكن لدي الوقت
لاختباره. بما أنني محبوس في رحلة غدًا ، سأفعل على أي حال :)

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/benoitc/gunicorn/issues/927#issuecomment -105652947.

كنت أعاني من نفس مشكلة DatabaseWrapper عندما رأيت هذا الموضوع.

أستطيع أن أؤكد أن إزالة الخيار preload_app من ملف تكوين gunicorn الخاص بي يعمل على إصلاح المشكلة. أنا استخدم:

• جانغو == 1.7.7
• gevent == 1.0.2
• جونيكورن == 19.3.0
• psycopg2 == 2.5.2
• psycogreen == 1.0
• غونيكورن ملفوفة بواسطة PgBouncer

(القفز إلى هنا منذ أن رأينا نفس المشكلات كما هو موضح في هذا الموضوع)

يبدو أن سبب هذه المشكلات هو إصلاح المشكلة رقم 478 (لا تقم بإصلاح القرد الرئيسي).

من خلال عدم قيام القرد بإصلاح التطبيق الرئيسي ، يؤدي التحميل المسبق للتطبيق بشكل أساسي إلى حدوث عدم تطابق إذا كنت تستخدم عمالًا جيفنت. يتم تشغيل أي كود تطبيق يتم تشغيله كجزء من التحميل المسبق في بيئة غير مصححة بشكل قرد. يتم تشغيل أي كود تطبيق يتم تشغيله في العامل في بيئة مصححة على شكل قرد.

بالنسبة لنا ، مجرد استعادة طريقة setup إلى فئة العمال gevent كما هو محدد في 18.x ، بحيث يتم تصحيح القرد الرئيسي ويتم تصحيحه قبل التحميل المسبق للتطبيق ، وإصلاح الكل قضايانا. يتضمن هذا الخطأ DatabaseWrapper ، بالإضافة إلى مشكلة أخرى كنا نراها حيث سيتوقف العمال الجادون وانقضاء المهلة. لم تكن هناك تغييرات أخرى الضرورية (ليس لدينا لتعطيل قرد الترقيع threads ، على سبيل المثال).

سأظل مترددًا جدًا في عملية التصحيح الرئيسية للقرد ، ولكن إذا كنت ترغب في القيام بذلك ، فقد تتمكن من استخدام خطاطيف الخادم بدلاً من تصحيح برنامج gunicorn نفسه. إذا كان بإمكانك فعل ذلك ، فسأرحب بأي طريقة يمكننا من خلالها توثيق ذلك في مكان ما أفضل من هنا.

أعتقد أن الخطة قصيرة المدى بالنسبة لنا هي إنشاء شوكة (داخلية) مع تطبيق هذا التصحيح.

سأحقق في نقل خطوة تصحيح القرد إلى كود wsgi الخاص بنا ، ولكن هذا لا يزال يبدو وكأنه شيء يجب القيام به داخل كود gunicorn (حتى كخيار قابل للتكوين). سيؤثر الترقيع في رمز التطبيق المحمّل مسبقًا على البرنامج الرئيسي بطريقة أو بأخرى ، وسيكون الهدف الأساسي هو الحفاظ على حالة القرد المصححة للعاملين متزامنة مع السيد. يعني تطبيق التصحيح الرئيسي للقرد في كود التطبيق أن مطوري التطبيقات الذين يعتمدون على هذا السلوك سوف يلعبون دائمًا لعبة اللحاق بكل التغييرات التي يقوم بها Gunicorn عندما / كيف يقوم القرد بتصحيح العامل.

إذا نجح التصحيح مبكرًا ، فربما ينبغي اعتبار ذلك بمثابة تغيير.

لا أتذكر ما إذا كان هذا هو الحال في أي وقت وما إذا كان ذلك يسبب مشاكل ، لكنه دائمًا ما يكون صعبًا مع ترقيع القرود.

يتطلب تطبيق gunicorn الإنتاجي الخاص بنا تحميلًا مسبقًا ، وبالتالي يتطلب أيضًا pserve لتشغيل التطبيق وتحميل gunicorn من ملف ini ؛ لدينا غلاف حوله ليكون تأكد من أن الترقيع القرد يحدث في أسرع وقت ممكن).

أنا مشرف حالي. يسعدني إلقاء نظرة على أية مشكلات مطلوبة لجعل هذا السيناريو يعمل بشكل أفضل. نتوقع إسقاط 1.1 قريبًا وسيكون رائعًا إذا كان هذا خيارًا مدعومًا.

لقد حاولت تطبيق نفس منطق تصحيح القرد في الجزء العلوي من تطبيق wsgi ، وبدأنا في رؤية المشكلة DatabaseWrapper . لست متأكدًا تمامًا من السبب - بالنظر إلى استدعاء wsgi في arbiter.py ، يحدث ذلك بعد بضعة أسطر من النقطة حيث سيتم استدعاء GeventWorker.setup (كأثر جانبي لتعيين فئة_العمل . إذا كنت أقرأ رمز الحق.

سأتابع ما إذا كان لدي eureka أو كنت محظوظًا فيما يتعلق برمز التطبيق ، ولكن حتى الآن بالنسبة لنا ، فإن التصحيح في وقت سابق في كود gunicorn الرئيسي هو الحل الوحيد الذي يحل جميع مشكلاتنا.

jamadden شكرا جزيلا.

jzupko من المهم عادةً أن يحدث الترقيع قبل أي واردات قد تتأثر. لهذا السبب اقترحت القيام بذلك في رابط الخادم ، مثل وضع دالة post_fork في ملف gunicorn.conf.py . ومع ذلك ، فقد أدركت للتو أن التحميل المسبق للتطبيق يحدث قبل أي خطاف للخادم وليس من الواضح أين يمكن للمرء أن يفعل ذلك.

benoitc هل لدينا أي آلية

أقوم بإضافة هذا إلى الإصدار 20 معلمًا وأقترح أن نعتبر أن القرد يرقع المعلم ، ربما ، إذا كان من الممكن القيام بذلك دون إعادة تقديم مشاكل مثل # 478.

tilgovi لديك طريقة العامل setup التي يمكن استخدامها لذلك على ما أعتقد.

هل لدى أي شخص إصلاح مؤقت لهذا حتى خروج 20.0؟ أم هو الحل الوحيد للاختيار بين تعطيل preload_app أو الرجوع إلى 18.0؟

@ fletom الإصلاح المؤقت ل؟ هل جربت أحدث سيد؟ هل عملت من أجلك؟

benoitc أعني إصلاحًا لخطأ "كائنات DatabaseWrapper".

لا يعمل سيد البونيكورن الحالي على الإطلاق بالنسبة لي في الواقع. في المعتاد 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 لم ينجح الإصلاح المقترح بالنسبة لي ، ما زلت أحصل على نفس الخطأ 😞

سأغلق هذا وأفتح مناقشة مع تسمية القائمة البريدية على علامة R20 الرئيسية لإصلاح القرد للحكم في gevent. إذا كنت تواجه مشكلات تتعلق بأي شيء في هذه المناقشة وتعتقد أنه قد يكون خطأ في Gunicorn ، فيرجى فتح مشكلة. يمكنك ذكر هذا بالرقم ، أو رابط للتعليقات ، إذا كان يساعد في إضافة سياق ، ولكن في هذه المرحلة ، هذه تذكرة قديمة مع محادثات متوازية حول عدة إصدارات من Gunicorn وأعراض مختلفة.