Gunicorn: خطأ OSE: [Errno 11] المورد غير متاح مؤقتًا في الإصدار 19.8.1 (و 19.8.0) على Heroku

تم إنشاؤها على ٢٩ مايو ٢٠١٨ · 14تعليقات · مصدر: benoitc/gunicorn

أنا أقوم بتشغيل خادم Flask بسيط على Heroku:

web: gunicorn --worker-class eventlet -w 1 app:app --log-file=-

يستخدم Python 2.7.15 للتوافق مع الحزم الأخرى المختلفة.

يبدو أنني واجهت نسخة مكررة من هذه المشكلة منذ زمن بعيد منذ انتقال Heroku إلى الإصدار 19.8.1. لن يتم تحميل بعض الصور (في أي مكان من حجم يتراوح من بضعة كيلوبايت إلى بضعة ميغا بايت) ؛ لدي موقع به الكثير من الصور (معظمها أوراق الرموز المتحركة للرسوم المتحركة) ويبدو أن مجموعة مختارة عشوائية منها لن يتم تحميلها في كل مرة ، كل منها يرمي الخطأ التالي (إذا كانت الصور مخزنة مؤقتًا من إصدار سابق ، يتم تحميلها بدون مشكلة) :

2018-05-29T09:24:36.216949+00:00 app[web.1]: [2018-05-29 09:24:36 +0000] [10] [ERROR] Socket error processing request. 2018-05-29T09:24:36.216969+00:00 app[web.1]: Traceback (most recent call last): 2018-05-29T09:24:36.216971+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/workers/async.py", line 66, in handle 2018-05-29T09:24:36.216972+00:00 app[web.1]: six.reraise(*sys.exc_info()) 2018-05-29T09:24:36.216974+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/workers/async.py", line 56, in handle 2018-05-29T09:24:36.216976+00:00 app[web.1]: self.handle_request(listener_name, req, client, addr) 2018-05-29T09:24:36.216978+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/workers/async.py", line 129, in handle_request 2018-05-29T09:24:36.216980+00:00 app[web.1]: six.reraise(*sys.exc_info()) 2018-05-29T09:24:36.216981+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/workers/async.py", line 112, in handle_request 2018-05-29T09:24:36.216983+00:00 app[web.1]: resp.write_file(respiter) 2018-05-29T09:24:36.216985+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 403, in write_file 2018-05-29T09:24:36.216987+00:00 app[web.1]: if not self.sendfile(respiter): 2018-05-29T09:24:36.216989+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/http/wsgi.py", line 393, in sendfile 2018-05-29T09:24:36.216990+00:00 app[web.1]: sent += sendfile(sockno, fileno, offset + sent, count) 2018-05-29T09:24:36.216992+00:00 app[web.1]: File "/app/.heroku/python/lib/python2.7/site-packages/gunicorn/http/_sendfile.py", line 66, in sendfile 2018-05-29T09:24:36.216994+00:00 app[web.1]: raise OSError(e, os.strerror(e)) 2018-05-29T09:24:36.216996+00:00 app[web.1]: OSError: [Errno 11] Resource temporarily unavailable

هذه هي الإصدارات الأخرى في requirements.txt:

Flask==0.12.2 gunicorn==19.8.1 pymongo==3.6.1 flask_socketio==2.9.6 flask_cors==3.0.3 eventlet==0.22.1 gevent==1.2.2

يبدو أن تغيير gunicorn إلى 19.7.1 يحل المشكلة ؛ استمرت مع 19.8.0.
كما هو الحال مع المشكلة المماثلة من عام 2012 ، فهي ليست مشكلة مهلة طلب لأن الخطأ الذي يلقي به يكون فوريًا جدًا. التراجع إلى 19.7.1 قد أصلحه ، لذلك سألتزم بذلك الآن ، لكن سيكون من الجيد استخدام أحدث إصدار. يبدو أن هذا يمكن أن يكون مشكلة خاصة بهيروكو ؛ لقد لاحظت فقط في الشهر الماضي أو نحو ذلك ، لكن لا يمكنني العثور على أي معلومات حول متى قاموا بتغيير الإصدارات.

مصدر

CCuskley

التعليق الأكثر فائدة

لقد حاربت مع هذه المشكلة نفسها اليوم ، طوال اليوم. وأعتقد أنني أصلحته أخيرًا. أنا أستخدم nginx و Flask و gunicorn w / eventlet و docker.

مخرجاتي (ذات الصلة) pip freeze :

eventlet==0.23.0
Flask==1.0.2
greenlet==0.4.14
gunicorn==19.9.0

أمر gunicorn الخاص بي:
gunicorn -b 0.0.0.0:8000 --workers 1 --worker-class eventlet --log-level=DEBUG myapp.wsgi:app

كان العارض الأول هو تحميل ملفات ثابتة كبيرة تؤدي إلى ظهور ERR_CONTENT_LENGTH_MISMATCH في المتصفح. من الواضح أن هذا أدى إلى كسر التطبيق ، حيث لم يتم تحميل حزم JS الثابتة الكبيرة.

العارض الثاني هو أن nginx يقوم بتسجيل ما يلي إلى error.log: upstream prematurely closed connection while reading upstream

أخيرًا ، تتبعت ذلك إلى عنصر سجل gunicorn:

Socket error processing request. - [in /usr/local/lib/python2.7/dist-packages/gunicorn/glogging.py:277]
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 66, in handle
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 56, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 129, in handle_request
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 112, in handle_request
    resp.write_file(respiter)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 403, in write_file
    if not self.sendfile(respiter):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 393, in sendfile
    sent += sendfile(sockno, fileno, offset + sent, count)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/_sendfile.py", line 66, in sendfile
    raise OSError(e, os.strerror(e))
OSError: [Errno 11] Resource temporarily unavailable

كان الحل النهائي لي أن أبدأ gunicorn بعلامة --no-sendfile ، واختفت المشكلة. لماذا ا؟ لست متأكدًا ... أنا سعيد لأنه يعمل.

تجدر الإشارة أيضًا ، أثناء تحري الخلل وإصلاحه ، بذلت قصارى جهدي لجعل nginx.conf يشبه المثال الموجود هنا: http://docs.gunicorn.org/en/stable/deploy.html

SaintSimmo في ٢٤ يوليو ٢٠١٨

❤4 👍4

ال 14 كومينتر

مخرجاتي (ذات الصلة) pip freeze :

eventlet==0.23.0
Flask==1.0.2
greenlet==0.4.14
gunicorn==19.9.0

أمر gunicorn الخاص بي:
gunicorn -b 0.0.0.0:8000 --workers 1 --worker-class eventlet --log-level=DEBUG myapp.wsgi:app

العارض الثاني هو أن nginx يقوم بتسجيل ما يلي إلى error.log: upstream prematurely closed connection while reading upstream

أخيرًا ، تتبعت ذلك إلى عنصر سجل gunicorn:

Socket error processing request. - [in /usr/local/lib/python2.7/dist-packages/gunicorn/glogging.py:277]
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 66, in handle
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 56, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 129, in handle_request
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 112, in handle_request
    resp.write_file(respiter)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 403, in write_file
    if not self.sendfile(respiter):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 393, in sendfile
    sent += sendfile(sockno, fileno, offset + sent, count)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/_sendfile.py", line 66, in sendfile
    raise OSError(e, os.strerror(e))
OSError: [Errno 11] Resource temporarily unavailable

كان الحل النهائي لي أن أبدأ gunicorn بعلامة --no-sendfile ، واختفت المشكلة. لماذا ا؟ لست متأكدًا ... أنا سعيد لأنه يعمل.

SaintSimmo في ٢٤ يوليو ٢٠١٨

❤4 👍4

أواجه هذه المشكلة أيضًا ، 19.7.0 تعمل بشكل جيد

ibuler في ١١ سبتمبر ٢٠١٨

هل يحدث هذا فورًا أم بعد إرسال رد طويل جزئيًا؟

tilgovi في ١٢ سبتمبر ٢٠١٨

قد يكون سبب ملف ثابت

ibuler في ١٢ سبتمبر ٢٠١٨

أي تحديث على هذا؟ أواجه نفس المشكلة في 19.9.0

كان كل شيء يعمل بشكل جيد وفجأة بدأ يحدث.

akhilputhiry في ١٢ أكتوبر ٢٠١٨

😕1

tilgovi اسمحوا لي أن أعرف إذا كنت بحاجة إلى بعض المعلومات بخصوص هذا. فجأة بدأت هذه المشكلة بالظهور

akhilputhiry في ٢٦ أكتوبر ٢٠١٨

بالنسبة لي كانت المشكلة بسبب عامل الحدث. أزلت الحدث الصغير وكل شيء على ما يرام الآن.

akhilputhiry في ٤ نوفمبر ٢٠١٨

أواجه نفس المشكلة. والاقتراح المقدم من SaintSimmo يعمل جيدًا بالنسبة لي. تحدث هذه المشكلة فور بدء تنزيل ملف كبير. أنا أستخدم القارورة والحدث الصغير. وتتم مهمة التنزيل عن طريق send_from_directory من Flask.
يبدأ gunicorn في الأمر التالي:
gunicorn - حدث فئة العمال -w 1 -b 0.0.0.0:4000 تحميل: التطبيق
الذي سيعطي الخطأ.
إذا تمت إضافة "- no-sendfile" في الأمر ، فلن يتم إرسال رسالة خطأ. إذا كان من الممكن القيام بمهمة التنزيل بدون "sendfile" ، فمتى يجب استخدام هذا "sendfile"؟

sodynamic في ١٩ نوفمبر ٢٠١٨

gunicorn (الإصدار 19.9.0) نفس المشكلة مع Eventlet

doomzhou في ١٨ يناير ٢٠١٩

👍6

في 19.9.0 ، عملت توصية SaintSimmo بتعيين --no-sendfile أيضًا بالنسبة لي.

jacebrowning في ٧ أبريل ٢٠١٩

👍3

نعم ، نفس المشكلة وبعد إزالة عامل الحدث تعمل بشكل جيد.

عندما أبدأ الخادم بهذا الأمر (gunicorn -w 1 -k eventlet -b 127.0.0.1:5000 wsgi: app) أتلقى الاستثناءات أدناه ويتم اقتطاع صورتي عند استجابة العميل.
[خطأ] طلب معالجة خطأ مأخذ التوصيل.
...
BlockingIOError: [Errno 11] المورد غير متاح مؤقتًا

إزالة تعريف فئة العامل ، فإنه يعمل.
gunicorn -w 1 -b 127.0.0.1:5000 wsgi: التطبيق

jacebrowning و SaintSimmo ، أؤكد أن المعلمة الإضافية - no-sendfile في الأمر gunicorn فعالة.

andre-carvalho في ١٢ أبريل ٢٠١٩

👍3

عادة ما يكون هذا بسبب أن nproc قليل جدًا ، يمكنك زيادة عدد nproc للمستخدم الذي يقوم بتشغيل هذا البرنامج عن طريق تحرير الملف ' /etc/security/limits.conf '.