Gunicorn: تنتهي مهلة عمال مزامنة Gunicorn على Docker + AWS

hrmmm من السجل أعلاه أستطيع أن أرى أن الوقت لا يتغير أبدًا. سأتأكد

شكرا ، أنا أقدر ذلك!

قد أتأثر بهذا الخطأ.

أقوم بتشغيل gunicorn داخل صورة Docker على AWS (Elastic Beanstalk + EC2 Container Service).
هناك مهلات ثابتة للعاملين تبدأ في الحدوث على الفور تقريبًا بعد التهيئة ، وفقط عند تشغيل صورة Docker على AWS.
يستغرق طلب HTTP نفسه أحيانًا بضع مللي ثانية ، وأحيانًا من 20 إلى 30 ثانية. لا يهم إذا كانت لصفحة غير موجودة ، أو صفحة بسيطة غير مصدق عليها "Hello world" أو صفحة تجلب السجلات من قاعدة بيانات.

تفاصيل إضافية :

• إصدارات Gunicorn : 19.5.0 و 19.6.0.
• صورة قاعدة Docker : python: 3.4 ( نظام التشغيل : Debian Jessie)
• إصدار Docker : 1.9.1 (مُدار بواسطة Amazon ECS) ، نظام التشغيل : Amazon Linux AMI 2016.03 (مُدار بواسطة Amazon EB).
• إطار تطبيق الويب : إصدارات Django 1.9.6 و 1.9.7.

البيئات _ غير المتأثرة :

• الجهاز المحلي ، داخل حاوية Docker و _ خارجها. نظام التشغيل : Ubuntu 16.04 LTS، Docker : 1.11.2.
• Heroku ( نظام التشغيل : Ubuntu 14.04 LTS)

سجلات حاويات أمازون :

[2016-06-15 16:46:15 +0000] [1] [DEBUG] Current configuration:
  cert_reqs: 0
  post_request: <function PostRequest.post_request at 0x7fb13e187c80>
  worker_connections: 1000
  tmp_upload_dir: None
  enable_stdio_inheritance: False
  timeout: 30
  pre_fork: <function Prefork.pre_fork at 0x7fb13e1871e0>
  worker_int: <function WorkerInt.worker_int at 0x7fb13e1876a8>
  backlog: 2048
  max_requests: 0
  max_requests_jitter: 0
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  logconfig: None
  syslog_addr: udp://localhost:514
  preload_app: False
  pidfile: None
  umask: 0
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  paste: None
  proxy_protocol: False
  worker_class: sync
  on_starting: <function OnStarting.on_starting at 0x7fb13e414c80>
  worker_abort: <function WorkerAbort.worker_abort at 0x7fb13e187840>
  worker_exit: <function WorkerExit.worker_exit at 0x7fb13e187e18>
  config: config/gunicorn.py
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7fb13e18a048>
  daemon: False
  accesslog: None
  errorlog: -
  loglevel: debug
  syslog_prefix: None
  ssl_version: 3
  suppress_ragged_eofs: True
  limit_request_field_size: 8190
  reload: False
  logger_class: gunicorn.glogging.Logger
  statsd_host: None
  keyfile: None
  raw_env: []
  threads: 1
  django_settings: None
  proc_name: None
  proxy_allow_ips: ['127.0.0.1']
  limit_request_fields: 100
  ciphers: TLSv1
  check_config: False
  do_handshake_on_connect: False
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7fb13e187510>
  graceful_timeout: 30
  worker_tmp_dir: None
  certfile: None
  sendfile: None
  keepalive: 2
  chdir: /app/testapp
  when_ready: <function WhenReady.when_ready at 0x7fb13e187048>
  ca_certs: None
  on_exit: <function OnExit.on_exit at 0x7fb13e18a1e0>
  spew: False
  bind: [':8000']
  post_fork: <function Postfork.post_fork at 0x7fb13e187378>
  limit_request_line: 4094
  syslog_facility: user
  workers: 3
  syslog: False
  pre_request: <function PreRequest.pre_request at 0x7fb13e187b70>
  user: 0
  group: 0
  forwarded_allow_ips: ['127.0.0.1']
  pythonpath: None
  on_reload: <function OnReload.on_reload at 0x7fb13e414e18>
  pre_exec: <function PreExec.pre_exec at 0x7fb13e1879d8>
  default_proc_name: config.wsgi
  statsd_prefix: 
[2016-06-15 16:46:15 +0000] [1] [INFO] Starting gunicorn 19.5.0
[2016-06-15 16:46:15 +0000] [1] [DEBUG] Arbiter booted
[2016-06-15 16:46:15 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2016-06-15 16:46:15 +0000] [1] [INFO] Using worker: sync
[2016-06-15 16:46:15 +0000] [8] [INFO] Booting worker with pid: 8
[2016-06-15 16:46:15 +0000] [9] [INFO] Booting worker with pid: 9
[2016-06-15 16:46:15 +0000] [10] [INFO] Booting worker with pid: 10
[2016-06-15 16:46:15 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2016-06-15 16:46:52 +0000] [9] [INFO] Worker exiting (pid: 9)
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:10)
[2016-06-15 16:46:52 +0000] [10] [INFO] Worker exiting (pid: 10)
[2016-06-15 16:46:53 +0000] [20] [INFO] Booting worker with pid: 20
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 2 workers
[2016-06-15 16:46:53 +0000] [21] [INFO] Booting worker with pid: 21
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:47:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:8)
(...)

"

شكرا.

انا ارى هذا ايضا شكوكي هو Elastic Load Balancer. اعتدنا على استخدام paste في شركة سابقة وكان هذا يسبب مشاكل مع ELB. أعتقد أنه يعيد استخدام الاتصالات بطريقة ما وكان هذا يتسبب في حدوث فوضى في paste .

أنا الآن في وظيفة جديدة حيث نستخدم gunicorn وكان كل شيء على ما يرام حتى بدأنا في وضع الخادم خلف ELB ، غالبًا ما يكون تطبيق الويب الآن غير مستجيب للغاية ويبدو أنه معلق.

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

فهل هذه مشكلة مع ELB للحفاظ على الاتصالات حية وربط عامل المزامنة؟ قد يبدو لي هذا غريبًا جدًا لأننا نشير عمداً إلى أنه يجب إغلاق الاتصال مع عامل المزامنة: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L168

ومع ذلك ، يمكننا إغلاق الاتصال عمدا. إذا أراد أي شخص اختبار نقل المكالمة client.close() لتكون غير مشروطة ، فقد يكون هذا اختبارًا مثيرًا للاهتمام: https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L199

يمكنك أيضًا التأكد من أن مهلة الخمول على ELB أقل من مهلة العامل ، كتحقق سريع من أن هذا هو سبب المشكلة: http://docs.aws.amazon.com/elasticloadbalancing/latest/ الكلاسيكية / config-idle-timeout.html

tilgovi ، الشيء elb هو أفضل تخميني الحالي ، لأنه أ) يحدث فقط إذا كان gunicorn وراء ELB و b) تم إصلاح المشكلة باستخدام العامل gevent . لكن ثم مرة من يعلم..

يحدث ذلك فقط خلف ELB ، وإذا تم تعيين بروتوكول HTTP أو HTTPS على ELB.
إذا قمت بتغيير البروتوكول إلى TCP أو SSL ، تختفي المشكلة.
هل يعرف أي شخص كيفية إصلاحه ما زال يستخدم عمال المزامنة؟ لقد استخدمت الإصلاح الذي وصفته (TCP بدلاً من HTTP) حتى الآن ، عندما سأراقب سجلات الوصول وأرى رأس X-Forwarded-For ، والذي يتم تمكينه فقط لـ HTTP / HTTPS على ELB :)

غريب ، فقط للتأكد من أننا على نفس الصفحة ، هذا يعني أن هناك نوعًا من التحسين عند استخدام خيار HTTP / HTTPS في ELB؟ وهذا التحسين يسبب مشاكل مع عمال المزامنة؟

ecs أعتقد أنه في حالة موازن تحميل HTTP / HTTPS

راجع للشغل ، هناك بالتأكيد الكثير من العوامل (إصدار gunicorn ، فئة العمال ، داخل عامل إرساء أم لا ، بروتوكول ELB) التي يمكن أن تؤثر ، لذلك قد يكون من الرائع أن يختبر شخص ما ويؤكد أن بروتوكول TCP على ELB يعمل على عكس HTTP. أنا أختبر على Docker المستضاف على Ubuntu 14.04 و Gunicorn الإصدار 19.3.0

لدي نفس المشكلة:
[2016-10-03 12:13:17 +0000] [6] [حرجة] المهلة الزمنية للعمال (رقم التعريف: 16)
[2016-10-03 12:13:17 +0000] [16] [INFO] خروج العامل (رقم التعريف: 16)
[2016-10-03 12:13:17 +0000] [6] [حرجة] مهلة العامل (pid: 20)
[2016-10-03 12:13:17 +0000] [20] [INFO] خروج العامل (رقم التعريف: 20)
[2016-10-03 12:13:17 +0000] [33] [INFO] تمهيد العامل مع رقم التعريف الشخصي: 33

الإعداد الخاص بي.

أنا أستخدم kube-aws لإعداد مجموعة kubernetes مع نظام التشغيل الأساسي على AWS: https://github.com/coreos/coreos-kubernetes/tree/master/multi-node/aws

لدي تطبيق python يستخدم عمال gunicorn و sync. تستخدم الخدمة الخاصة بهم موازن تحميل HTTPS مع شهادة المواقع الخاصة بي. يتم اعتبار جميع العمال منتهية المهلة بعد وقت انتهاء المهلة الافتراضي وهو 30 ثانية على ما يبدو. يتم إعادة تشغيلهم جميعًا في النهاية. يقوم Kubernetes في النهاية بإعادة تشغيل الحاوية عند الخروج .. تحدث عمليات إعادة التشغيل هذه بشكل مستمر. ذكر شخص ما أعلاه أن gevent يحل المشكلة التي قد أجربها ولكني أود حقًا أن أفهم سبب حدوث ذلك.

نحن نشهد هذه المشكلة أيضًا حاليًا ، سأحاول نشر المزيد من التفاصيل عندما تسنح لي الفرصة. إنه مرتبط بعامل المزامنة حيث أن الانتقال إلى gevent يحل المشكلة بالفعل. هذا موجود على AWS مع ECS و ELB.

واجهت نفس المشكلة الغريبة أيضًا مع أحد تطبيقاتنا. إن تغيير المستمعين من HTTP إلى tcp يحل المشكلة بالفعل.

يمكن لأي شخص أن يقدم لي طريقة خطوة بخطوة لإعادة إظهار المشكلة؟ (خطوة التكوين وما شابه) أو على الأقل وجهني إلى طريقة بسيطة لإعداد تلك البيئة :) سألقي نظرة عليها هذا الأسبوع.

يتطلب الاعتماد على HTTP لمثل هذا الموازن عمومًا التعامل مع الاستمرار ، (باستثناء tcp) ، لذلك قد يمثل أي شيء يستخدم عامل المزامنة مشكلة حتى يتم تحديث عامل المزامنة لدعمه.

على أي حال اسمحوا لي أن أعرف.

ما عليك سوى إعداد تطبيق Flask الأساسي وتشغيله مع gunicorn مع عمال المزامنة داخل docker على AWS ، مع موازنة تحميل HTTP والتكوين من الأعلى:

باستخدام gunicorn 19.4.5 داخل صورة عامل إرساء ، والتي تعمل على Ubuntu 14.04 LTS على AWS ، أرى مهلات ثابتة للعاملين عند التشغيل مع> عامل مزامنة واحد وفترة المهلة الافتراضية 30 ثانية.

لا يتعين عليك تقديم أي طلبات إلى التطبيق ، ما عليك سوى مراقبة السجلات وسترى انتهاء مهلة العاملين.

• يمكنني تأكيد هذا السلوك وكذلك النهج الأساسي لإعادة إنتاجه.
  
  
  
  • لا يقتصر السلوك على Docker بل على عامل المزامنة / إعداد Keepalive ، لذلك يمكنك التفكير في تغيير العنوان ...
  
  
• لقد قمت بتعديل إعداد Keepalive لاتباع ما هو موصوف هنا: https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ (الجزء الأكثر إثارة للاهتمام هو الاقتباس من وثائق AWS ELB) ووجدت أن الخادم لم يعد يعرض هذا السلوك بعد الآن.
• علاوة على ذلك ، لقد غيرت أيضًا إلى فئة عمال خيط gthread ووجدت النتيجة مقبولة جدًا حتى الآن.

أستخدم حاليًا عمالًا gevent مع فترة مهلة 65 ثانية (مهلة AWS ELB هي 60 ثانية ، AFAIK). ما زلت أحيانًا أواجه أخطاء 504 حتى عندما يقوم عميل واحد فقط بتقديم طلبات ، مع طلب واحد أثناء الرحلة في كل مرة ، لكنني لم أتمكن من تحديد سبب حتى الآن.

@ obi1kenobi هل حاولت زيادة قيمة Keepalive إلى ما بعد خيار مهلة ELB؟

lenucksi the keepalive أعلى بالفعل من مهلة ELB بمقدار 5 ثوانٍ - نأمل ألا تعمل ساعات الخوادم كثيرًا :)

لقد واجهت أيضًا هذه المشكلة أثناء تشغيل gunicorn 19.6 داخل حاوية Docker على مثيل EC2 خلف ELB (باستخدام بروتوكول HTTP الافتراضي للوكيل العكسي لمثيل EC2).

كما تم اقتراحه سابقًا ، أدى تعيين فئة العمال إلى حل هذه المشكلة بالنسبة لي (حيث كنت أستخدم سابقًا فئة العمال الافتراضية sync ).

سأحاول وتوثيق مثال بسيط لإعادة إظهار المشكلة.

لتأكيد ما قاله الآخرون ، يبدو أن ELB يفتح اتصالاً بمثيل EC2 ويبقيه مفتوحًا بطريقة تمنع gunicorn من التعامل مع الطلبات الإضافية.

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

يشير هذا العرض إلى أن هذه نسخة مكررة مما لوحظ في هذه المشكلة السابقة والتي لا علاقة لها بـ Docker: https://github.com/benoitc/gunicorn/issues/588

jelis هل تعرف ما إذا كان هذا مرتبطًا ببعض إعدادات kubernetes؟ هل تم حل مشكلتك؟

أنا أيضًا في ELB مع إنهاء SSL. أرى هذا في سجلاتي:

[017-03-01 07:36:32 +0000] [1249] [DEBUG] GET /healthcheck
[01/Mar/2017:07:36:32 +0000] "GET /healthcheck HTTP/1.1" 200 22 "-" "ELB-HealthChecker/1.0"
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1203)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1225)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1234)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1243)
[017-03-01 07:36:37 +0000] [1203] [INFO] Worker exiting (pid: 1203)
[017-03-01 07:36:37 +0000] [1225] [INFO] Worker exiting (pid: 1225)
[017-03-01 07:36:37 +0000] [1243] [INFO] Worker exiting (pid: 1243)
[017-03-01 07:36:37 +0000] [1234] [INFO] Worker exiting (pid: 1234)
[017-03-01 07:36:37 +0000] [1256] [INFO] Booting worker with pid: 1256
[017-03-01 07:36:37 +0000] [12] [DEBUG] 14 workers
[017-03-01 07:36:37 +0000] [1257] [INFO] Booting worker with pid: 1257
[017-03-01 07:36:37 +0000] [1262] [INFO] Booting worker with pid: 1262
[017-03-01 07:36:37 +0000] [1265] [INFO] Booting worker with pid: 1265
[017-03-01 07:36:37 +0000] [12] [DEBUG] 16 workers
[017-03-01 07:36:40 +0000] [1262] [DEBUG] GET /healthcheck

تحديث - لقد تحولت للتو من gunicorn إلى gevent (http://flask.pocoo.org/docs/0.12/deploying/wsgi-standalone/#gevent) وتم حل المشكلة. هذا في إشارة إلى تعليقي أعلاه https://github.com/benoitc/gunicorn/issues/1194#issuecomment -283269046

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

لقد حاولت للتو استخدام gevent مع زيادة في عدد العمال وهذا لم يساعدنا على الإطلاق - في الواقع جعل الأمر يبدو أسوأ بشكل مدهش - مات جميع العمال الخمسة في نفس الوقت ، وهو سلوك جديد من ما قرأته أعلاه:

[2017-03-30 23:38:37 +0000] [5] [INFO] Starting gunicorn 19.7.1
[2017-03-30 23:38:37 +0000] [5] [INFO] Listening at: http://0.0.0.0:8000 (5)
[2017-03-30 23:38:37 +0000] [5] [INFO] Using worker: eventlet
[2017-03-30 23:38:38 +0000] [8] [INFO] Booting worker with pid: 8
[2017-03-30 23:38:40 +0000] [9] [INFO] Booting worker with pid: 9
[2017-03-30 23:38:41 +0000] [11] [INFO] Booting worker with pid: 11
[2017-03-30 23:38:42 +0000] [12] [INFO] Booting worker with pid: 12
[2017-03-30 23:38:42 +0000] [10] [INFO] Booting worker with pid: 10
[2017-03-30 23:40:08 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:8)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:10)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-03-30 23:40:13 +0000] [8] [INFO] Worker exiting (pid: 8)
[2017-03-30 23:40:13 +0000] [10] [INFO] Worker exiting (pid: 10)
[2017-03-30 23:40:16 +0000] [16] [INFO] Booting worker with pid: 16
[2017-03-30 23:40:16 +0000] [17] [INFO] Booting worker with pid: 17
[2017-03-30 23:40:18 +0000] [18] [INFO] Booting worker with pid: 18
[2017-03-30 23:40:20 +0000] [19] [INFO] Booting worker with pid: 19
[2017-03-30 23:40:23 +0000] [20] [INFO] Booting worker with pid: 20

من المحتمل أن يكون هذا خطأً من جانبي ، ولم يكن نفس السلوك الذي كان عليه أحد نظرائي في المشروع (مع قاعدة شفرة مماثلة ولكن ليست متطابقة في نشر AWS / CloudFormation / ALB / ECS شبه متطابق). ومع ذلك ، فقد اكتشفت أنني سأبلغ عن ذلك في حال كان يلهم أي رؤى جديدة حول التفاعلات بين ALB و ECS و Docker و gunicorn.

لدي إعداد مماثل (convox يعمل على ELB-> ECS Docker Container-> Gunicorn-> Django) ويمكنني أن أؤكد أن تغييرات التكوين التالية يبدو أنها ساعدت:

keepalive = 75 # needs to be longer than the ELB idle timeout
timeout = 90
worker_class = 'gevent'

لقد قمت بتعيين مهلة الخمول ELB الخاصة بي على 60 ثانية.

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

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

تتراكم فقط ، لا يوجد عامل رصيف ، ولكن حالة العار العارية كانت تواجه نفس المشكلة وراء ELB. يعمل NP على osx ، ولكن تم اقتصاص ubuntu16 مع مشكلة ELB نفسها. يبدو أن فئة العمال gevent تصلح المشكلة [من أجلي].

يمكن لأي شخص في هذا الموضوع التحقق من هذا؟
https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx

يبدو أن erikcw قد وجد هذا الحل للعمل. أود أن أغلق هذه القضية. إذا كان بإمكان أي شخص إعادة إنتاج هذا بعد رفع مهلة عامل Gunicorn ووقت البقاء على قيد الحياة ، فيرجى ذكر ذلك.

بدلاً من ذلك ، قم بخفض مهلة الخمول لـ ELB.

ألا يمكن أن يتصرف عميل في البرية (أو عميل شرير) مثل ELB ويسبب نفس المشكلة؟

@ six8 نعم. لا يحميك ELB من هذا أيضًا. تناقش الوثائق هذا: http://docs.gunicorn.org/en/latest/design.html#choosing -a-worker-type

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

لقد جربت حل erikcw أيضًا من خلال تغيير استدعاء gunicorn إلى:

CMD [ "gunicorn", "-k", "gevent", "--timeout", "10", "--keep-alive", "75", "--paste", "/etc/jzoo/app.ini" ]

للأسف هذا لا يساعد:

[2017-07-04 08:36:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:24)
[2017-07-04 08:38:11 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:28)
[2017-07-04 08:39:39 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:29)
[2017-07-04 08:44:14 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-07-04 08:44:55 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:31)

لدي تطبيق يعمل على ECS خلف ALB مع عمال مزامنة Gunicorn. لم أر أي مشكلة حتى الآن.

هل يمكن لأي شخص توفير نشر قابل للتكرار؟

تتراكم ، كذلك. رؤية هذه المشكلة باستخدام Kubernetes على AWS مع ELB. حاليا 8 عمال يعملون. لكل https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ ، سنقوم بزيادة keepalive ، وفي هذا الموضوع سنحاول لاستخدام عمال gevent بدلاً من ذلك. ولكن في الوقت الحالي ، ما فشل هو بعض اختبارات الأداء لمكالمات واجهة برمجة التطبيقات التي لا ينبغي أن تمنع / تتسبب في انقضاء المهلات من تلقاء نفسها. يود معرفة ما يحدث هنا مع العمال sync . حتى إذا نجحنا في العمل وفقًا لبعض الإرشادات الجيدة في هذا الموضوع ، فإننا نرغب في مزيد من الثقة فيما يحدث قبل النشر في الإنتاج.

لقد نجح تعيين فئة العامل إلى --worker-class gevent بالنسبة لي. شكرا على التعليقات والمساعدة!

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

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

tilgovi لقد واجهت هذه المشكلة عند عدم تحديد فئة العمال التي يجب منعها (على سبيل المثال ، استخدام عامل المزامنة الافتراضي). الإعداد الخاص بي هو virtualenv باستخدام pypy3 (PyPy 5.8.0-beta0) ، falcon 1.2 ، وما إلى ذلك (فهم أن Falcon غير مدعوم رسميًا مع pypy3). لقد استخدمت ملف تعريف الارتباط من https://github.com/7ideas/cookiecutter-falcon وقمت بالترقية إلى جميع الحزم الأحدث وفي محاولة تحميل sample_resource في المتصفح وضربه عدة مرات باستخدام httpie سيؤدي إلى رؤية خطأ تحطم العامل بشكل متقطع ( على سبيل المثال ، سيتم تأجيل الطلب وبعد ذلك سأرى الخطأ ؛ إذا لم ألغ الطلب فسوف يستجيب في النهاية). حدث هذا فقط مع فئة العاملين الافتراضية للمزامنة. عندما حددته لاستخدام gevent ، نجح كل شيء.

شكرًا لك ، @ jhillhouse92 ،

ما زلت أرى مشاكل المهلة ،tilgovi. سأقوم باستكشاف هذا الخطأ أكثر غدًا وسأنشر تحديثًا بمعلومات أكثر دقة. الرجاء إبقاء هذه المسألة مفتوحة؛ أنت محق في أنه قد تكون هناك مجموعة متنوعة من المشكلات التي تحدث ، ولكن الموضوع العام هو أن عمال gunicorn (ربما فقط مع فئة عمال المزامنة ، tbd) يواجهون مشكلات في المهلة عند استخدام gunicorn مع تطبيق تم نشره باستخدام AWS / ELB. هناك شيء خاطئ هنا ، حتى لو لم نقم بعزل المشكلة بالضبط. الأمر يستحق المزيد من البحث. سوف أقوم بتحديث غدا.

تجدر الإشارة إلى أنني واجهت هذه المشكلة محليًا ليس ضمن Docker / AWS / ELB مع المكدس أعلاه الذي ذكرته.

لذا فأنا أستخدم gevent ، وأحاول التقاط سجلات الوصول الخاصة بي ، وأحاول نشر تطبيقي باستخدام AWS / ELB.

أوامر dockerfile:

FROM cortex/base

CMD ["gunicorn", "-w", "8", "-b", "0.0.0.0:5000", "--capture-output", "--enable-stdio-inheritance", "--access-logfile", "-", "--worker-class", "gevent", "-t", "60", "--log-level", "debug", "app:app"]

أحصل على أخطاء OOM مجنونة فيما يتعلق برمز الخطأ 14 ، بغض النظر عما قمت بتعيينه للحدود. هل رأى أي شخص آخر هذا في سياق هذه القضية؟ في السابق ، كنت قادرًا على رؤية مهلات العامل. باستخدام تكويناتي الحالية ، لا يمكنني إعادة إنتاج المهلات / الوصول إلى هذا الحد.

[2017-07-19 18:27:39 +0000] [34] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/ggevent.py", line 190, in init_process
    super(GeventWorker, self).init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.load_wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/usr/local/lib/python3.5/site-packages/gunicorn/util.py", line 376, in import_app
    __import__(module)
  File "/code/app/__init__.py", line 2, in <module>
    from flask_alchy import Alchy
  File "/usr/local/lib/python3.5/site-packages/flask_alchy.py", line 8, in <module>
    from flask_sqlalchemy import SQLAlchemy
  File "/usr/local/lib/python3.5/site-packages/flask_sqlalchemy/__init__.py", line 18, in <module>
    import sqlalchemy
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/__init__.py", line 9, in <module>
    from .sql import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/__init__.py", line 8, in <module>
    from .expression import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/expression.py", line 34, in <module>
    from .functions import func, modifier, FunctionElement, Function
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/functions.py", line 11, in <module>
    from . import sqltypes, schema
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 658, in exec_module
  File "<frozen importlib._bootstrap_external>", line 763, in get_code
  File "<frozen importlib._bootstrap_external>", line 816, in get_data
OSError: [Errno 14] Bad address

للتكرار ، لا أرى هذا محليًا بدون عامل ميناء. لا أرى هذا محليًا مع Docker. تصبح هذه المشكلات والمهلة فقط ظاهريًا في حزمة Docker / AWS / ELB (بالنسبة لي).

tilgovi أحد الأشياء التي

gunicorn -k gevent --timeout 90 --keep-alive 75 --paste /etc/jzoo/app.ini "$@"

يبدو ملف .ini بالشكل التالي:

[DEFAULT]
sqlalchemy.url = postgresql://XXXX

[app:main]
use = egg:jzoo.api.admin

[server:main]
use = egg:gunicorn#main
bind = 0.0.0.0:5000
workers = 4
preload_app = true
loglevel = warning

# Logging configuration
[loggers]
keys = root,sqlalchemy,alembic,jzoo

# .. more logging configuration

لا يبدو أن حجم حركة المرور يمثل عاملاً - أرى أن هذا يحدث في بيئة ضمان الجودة لدينا والتي لا ترى سوى القليل جدًا من حركة المرور.

بالنظر إلى عدد مرات حدوث ذلك ، أتساءل عما إذا كان هذا يمكن أن يكون مرتبطًا بإعادة تشغيل التطبيق؟

لدي مشكلة مشابهة إلى حد ما. بعد بعض التحقيقات ، أعتقد أنه من المحتمل أن يكون خطأ في اتصال الشبكة ، وليس خطأ في gunicorn.

هذا هو الإعداد الخاص بي:

• يعمل خادم Postgresql على Docker على EC2. صورة عامل ميناء هي postgres 9.6 الرسمية.
• يعمل خادم التطبيقات على Docker في جهاز افتراضي خارج EC2. صورة عامل ميناء هي النسخة الرسمية من بيثون 3.6.
• يتم فتح المنفذ 5432 / tcp فقط في مجموعة أمان AWS.

من المضحك أن معظم الطلبات من خادم التطبيق إلى خادم postgres كانت مقبولة ، باستثناء طلب واحد. يبدو أن هذا الاستعلام يعمل إلى الأبد ، مما يؤدي إلى إنهاء مهلة العامل الجوني كورن.

اختفت المشكلة إذا كنت أستخدم التطبيق محليًا.

اختفت المشكلة أيضًا إذا لم أقم بإرساء خادم التطبيق.

الإصلاح الزمني الخاص بي مفتوح لجميع الاتصالات بين خادم التطبيق وخادم postgres من خلال إعداد مجموعة أمان AWS. الآن كل شيء يعمل بشكل صحيح مرة أخرى.

أعتقد أن هناك مشكلة في الاتصال بين حاوية Python و AWS. سأقوم بالتحديث بعد فحص تدفق سجل AWS بدقة.

شكرا لك!! نجح تغيير بروتوكول ELB و Instance من HTTP إلى TCP على ما يرام 👍

لا تبدو المشكلة خاصة بـ AWS ، ولكنها تبدو خاصة بـ Docker نفسها عند دمجها مع Gunicorn. أرى هذا أيضًا مع gevent ، على الأقل في بيئة الإنتاج لدينا.

tilgovi إليك تطبيق بسيط لإعادة إنشاء هذا الخطأ (بين الحين والآخر ، لم تعثر على النمط ، ربما يمكنك ذلك):

app.py:

import falcon


class HelloResource:
    def on_get(self, req, resp):
        resp.media = {'info': 'hello world'}


app = falcon.API()
app.add_route('/', HelloResource())

ملف Docker:

FROM python:3.6
WORKDIR /code
RUN pip install gunicorn falcon
COPY app.py .
CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

للتشغيل: docker build -t gunicorn-and-docker . && docker run -p 8000:8000 -it --rm gunicorn-and-docker

ستبدو السجلات بهذا الشكل (على الأقل بالنسبة لي على macOS Sierra باستخدام Docker 17.06.2-ce-mac27 (19124)):

[2017-09-23 22:31:00 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-09-23 22:31:00 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2017-09-23 22:31:00 +0000] [1] [INFO] Using worker: sync
[2017-09-23 22:31:00 +0000] [9] [INFO] Booting worker with pid: 9
[2017-09-23 23:22:45 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-09-23 23:22:45 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-09-23 23:22:45 +0000] [11] [INFO] Booting worker with pid: 11
[2017-09-23 23:39:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-09-23 23:39:46 +0000] [11] [INFO] Worker exiting (pid: 11)
[2017-09-23 23:39:46 +0000] [13] [INFO] Booting worker with pid: 13
[2017-09-23 23:41:10 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:13)
[2017-09-23 23:41:10 +0000] [13] [INFO] Worker exiting (pid: 13)
[2017-09-23 23:41:10 +0000] [15] [INFO] Booting worker with pid: 15
[2017-09-23 23:42:27 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:15)
[2017-09-23 23:42:27 +0000] [15] [INFO] Worker exiting (pid: 15)
[2017-09-23 23:42:27 +0000] [17] [INFO] Booting worker with pid: 17
[2017-09-23 23:43:44 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:17)
[2017-09-23 23:43:44 +0000] [17] [INFO] Worker exiting (pid: 17)
[2017-09-23 23:43:44 +0000] [19] [INFO] Booting worker with pid: 19
[2017-09-24 18:37:12 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:19)
[2017-09-24 18:37:12 +0000] [19] [INFO] Worker exiting (pid: 19)
[2017-09-24 18:37:12 +0000] [21] [INFO] Booting worker with pid: 21
[2017-09-24 19:49:20 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:21)
[2017-09-24 19:49:20 +0000] [21] [INFO] Worker exiting (pid: 21)
[2017-09-24 19:49:20 +0000] [23] [INFO] Booting worker with pid: 23
[2017-09-24 19:50:37 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:23)
[2017-09-24 19:50:37 +0000] [23] [INFO] Worker exiting (pid: 23)
[2017-09-24 19:50:37 +0000] [25] [INFO] Booting worker with pid: 25
[2017-09-24 20:25:48 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-09-24 20:25:48 +0000] [25] [INFO] Worker exiting (pid: 25)
[2017-09-24 20:25:48 +0000] [27] [INFO] Booting worker with pid: 27

أهلا،

لقد اصطدمت مؤخرًا بنفس المشكلة.
في حالتي (ECS + gunicorn 19.7.1 + Django 1.11.5) تمكنت (على ما يبدو) من حلها ببساطة عن طريق زيادة كمية الذاكرة المخصصة للحاوية في تعريف المهمة (من 128 إلى 256 ميجابايت).
لا مزيد من الأخطاء حتى الآن. سأبلغ هنا إذا حدث ذلك مرة أخرى.

أضف إلى الكورس هنا قليلاً ، لكنني تمكنت من حل هذا فقط عن طريق التبديل إلى gevent.

حاولت زيادة المهلة إلى 90 والبقاء على قيد الحياة إلى 75 مع عامل المزامنة دون حظ.

ومن المثير للاهتمام أيضًا أن ELB الخاص بي في هذا السيناريو يقوم فقط بإعادة توجيه مستوى TCP وليس HTTP.

حسنًا ، لقد وجدت بعض المراجع التي تشرح ذلك. [1]

يمكن حلها بتغييرات صغيرة على جانب جونيكورن. إذا ، في عامل المزامنة ، بعد قبول اتصال جديد ، استدعينا select() مع مهلة قصيرة ، فيمكننا التعامل مع هذه الاتصالات. يمكن أن يصبح الأمر معقدًا بعض الشيء ، خاصة مع مآخذ الاستماع المتعددة. أبسط شيء هو الحصول على مهلة للبايت الأول. لست متأكدًا من كيفية تفاعل ذلك مع SSL أيضًا.

[1] https://cloudavail.com/2013/12/21/aws-elb-pre-open-connection-expose-part-1/

إذا كنت تواجه هذا ولا تريد استخدام gevent / eventlet / asyncio ، فإنني أوصي بالتبديل إلى العامل المترابط (قدم الإعداد --threads ).

tilgovi @ يبدو أن المشكلة موجودة مع gevent worker أيضًا ، إذا نظرت إلى المثال أعلاه.

jmagnusson مثالك (من هذا التعليق: https://github.com/benoitc/gunicorn/issues/1194#issuecomment-331740187) يبدو أنه يستخدم عامل المزامنة.

[2017-09-23 22:31:00 +0000] [1] [INFO] استخدام العامل: المزامنة

tilgovi صحيح ، لكنني واجهت هذا مع العامل gevent أيضًا ، في الإنتاج. سأحاول أن أجد بعض الوقت للتكاثر مع gevent.

قد يكون هذا أنا فقط (سخيف) ، ولكن في مجموعة أمان EC2 -> القواعد الواردة ، لدي قاعدة TCP مخصصة للمنفذ 5000 (gunicorn هنا) للسماح لعنوان IP واحد فقط (عنوان IP الخاص بي: XX.XX.XX.XX / 32) ، فإن تغيير هذا إلى كل IP سيساعد.

أنا ألتقي بالمشكلة أيضًا.

[2018-01-02 16:38:03 +0800] [24355] [INFO] Starting gunicorn 19.7.1
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] Arbiter booted
[2018-01-02 16:38:03 +0800] [24355] [INFO] Listening at: http://0.0.0.0:8080 (24355)
[2018-01-02 16:38:03 +0800] [24355] [INFO] Using worker: gevent
[2018-01-02 16:38:03 +0800] [24358] [INFO] Booting worker with pid: 24358
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] 1 workers
[2018-01-02 16:38:03 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:04 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:05 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:06 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:07 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:08 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:09 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:10 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] Closing connection. 
[2018-01-02 16:38:41 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24358)
[2018-01-02 16:38:41 +0800] [24358] [INFO] Worker exiting (pid: 24358)
[2018-01-02 16:38:41 +0800] [24381] [INFO] Booting worker with pid: 24381
[2018-01-02 16:38:41 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:42 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:43 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:44 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:45 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:46 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:47 +0800] [24381] [INFO] worker pid 24381 notify
......
[2018-01-02 16:48:20 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:48:51 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24381)
[2018-01-02 16:48:51 +0800] [24381] [INFO] Worker exiting (pid: 24381)
[2018-01-02 16:48:51 +0800] [24703] [INFO] Booting worker with pid: 24703
[2018-01-02 16:48:51 +0800] [24703] [INFO] worker pid 24703 notify
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] Closing connection. 

أضفت سجل التصحيح worker pid {WORKER_PID} notify .

وفقًا لسجل التصحيح ،

1. فقط إذا تلقت عملية العامل طلبًا واحدًا ، فلن يستمر الإعلام. لذا ، سواء كانت هناك طلبات أم لا ، فإن السيد سيقتل عملية العامل بعد 30 ثانية.
2. بمجرد إغلاق الطلب الأول ، قمت بإرسال الطلب الثاني الآن ، ولكن تم حظر الطلب الثاني ولا يوجد استجابة. عندما وصلت مهلة الثلاثينيات ، تم إنهاء عملية العامل وستستجيب عملية العامل الجديد للطلب الثاني. ثم تم تعليق الخادم مرة أخرى.
3. عندما يتم تعليق العملية المنفذة ، فإنها لن تتلقى إشارة من السيد ، مثل SIGTERM . عندما تصل المهلة الرائعة ، سيقتلها السيد بمقدار SIGKILL قسري.

Python: 3.6.3
Gevent: 1.2.2
Gunicorn: 19.7.1
RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

إشعار: عندما أستخدم eventlet كعامل ، فلا بأس بذلك.

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

tilgovi FWIW رأيت هذا مع ALB. لم أستخدم موازين التحميل الكلاسيكية مطلقًا.

tilgovi لقد لاحظت هذا أيضًا مرارًا وتكرارًا في بيئات ALB فقط ، ولم أستخدم الكلاسيكية مطلقًا. حتى مع تعديلات مهلة العامل ، واصلنا رؤية هذا.

tilgovi التقيت بهذا. لم أستخدم AWS مطلقًا.

يجب على شخص ما المساعدة في إعادة إنتاج هذا ، ثم محاولة تصحيحه. لا يمكنني إعادة إنتاجه باستخدام ALB ولا يمكنني معرفة كيفية إعادة إنتاجه خارج AWS.

xgfone ، قد ترغب في فتح مشكلتك الخاصة ، عنوان هذه المشكلة هو "docker + AWS"

هل جرب أي شخص ذلك مع موازنات تحميل AWS ولكن بدون Docker؟ أنا مرتبك قليلاً ، يجب أن أعترف :)

كان انطباعي أن المشكلة كانت أكثر ارتباطًا بـ Docker - على الأقل كان لدي نفس المشكلات تمامًا أثناء تشغيل العديد من عمال مزامنة gunicorn داخل Docker على جهازي المحلي.

كان هذا التكوين يعمل بشكل جيد بدون Docker على أجهزة Ubuntu و RHEL ، سواء المعدنية أو الافتراضية في Digital Ocean:

workers = 2
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

داخل Docker (أيضًا RHEL ، كل شيء آخر هو نفسه) ، واجه العمال دائمًا مهلة واستمروا في إعادة التشغيل بشكل دائم. من خلال أخذ التوصيات من هذا الموضوع ، قمت بالتبديل إلى هذا ، والذي يعمل بشكل جيد تمامًا:

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

إذا كنت تعتقد أن هذا ليس له علاقة بهذا الموضوع ، يسعدني إزالته من هنا ووضعه في مكان آخر ؛-)

أفضل ، بوريس

تضمين التغريدة

يحدث هذا الخطأ في arbiter.py ، murder_workers . يتم استدعاء الوظيفة murder_workers عندما يكون SIG_QUEUE فارغًا (على سبيل المثال أثناء انتظار الإشارات).

عندئذٍ سيتحقق لمعرفة ما إذا كان قد تم الوصول إلى المهلة كل ثانية. كان الوقت المتبقي للعيش دائمًا 1 ثانية أو 0 ثانية لأن العامل gevent في حلقة لا نهائية مضبوطة بينما قام self.alive باستدعاء self.notify الذي يقوم بتحديث الملف. تحديثات الملف هي الطريقة التي يفحص بها برنامج Gunicorn وقت حدوث آخر وقت نشط.

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

handle_quit
handle_request (إذا تم استلام الحد الأقصى من الطلبات ، فسيكون هذا افتراضيًا 2 ^ 64 بت من عدد الطلبات أو 2 ^ 32 إذا كان نظام التشغيل 32 بت)
changed (يتم استدعاؤه من أداة إعادة التحميل إذا تم تغيير الملف)
handle_exit
handle_abort

يتم استدعاء هذه الطرق من الإشارات

handle_quit - SIGQUIT ، SIGINT
handle_exit - SIGTERM
handle_abort - SIGABRT

وبالتالي ، هناك مشكلتان محتملتان أراهما:

1. طريقة الإخطار غير قادرة على تحديث الملف أثناء حلقته
2. يتم إرسال إشارة بشكل غير صحيح

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

• StopIteration
• KeyboardInterrupt
• HaltServer
• Exception (استثناء غير معالج)

أعتقد أن استثناء StopIteration هو على الأرجح السبب الذي تم تشغيله في ملف async.py عند req = six.next(parser) . يبدو أن هذه الطريقة التالية تستدعي فقط parser.next ().

Parser.next() رفع استثناء StopIteration للشرطين التاليين:

1. If the message indicates it should close:
    1. http Connection close (and keep-alive false)
    2. WSGI - request method not HEAD, response_length is none, and status code is > 200 (but not 204, or 304)
2. If self.mesg (Request message) is falsey

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

سأعيد فتح هذا وأحاول اختبار هذه المجموعات:

• عامل ميناء محلي
• Docker AWS مع Classic Load Balancer
• Docker AWS مع Application Load Balancer

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

أواجه هذه المشكلة ولا أستخدم AWS.
الإعداد الخاص بي هو NGINX -> حاوية Docker (Gunicorn مع عمال gevent + Django). أنا أستخدم المهلات الافتراضية لـ Gunicorn.

أي نصائح؟

شكرا.

مرحبًا davidmir ،
واجهت نفس المشكلة ، ولم يساعد تغيير نوع العامل. أدى التبديل إلى عامل مزامنة واحد مع سلاسل رسائل متعددة إلى الحيلة بالنسبة لي:

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

أفضل ، بوريس

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

هذا يمثل مشكلة خاصة على Docker إذا كان لديك شيء مثل هذا في التكوين الخاص بك:

workers = multiprocessing.cpu_count() * 2 + 1

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

على الرغم من اختلافها من تطبيق إلى آخر ، فإن القاعدة الأساسية الخاصة بي هي 256 ميغا لكل عامل في تكوين بسيط و 512 ميغا للأمان.

واجهت نفس المشكلة باستخدام Classic ELB HTTPS => HTTP Gunicorn Sync Workers

كما ذكر آخرون ، كان الحل الأسهل هو استخدام وسيطة -k gevent بدلاً من عامل المزامنة الافتراضي.

لقد رأينا هذه المشكلة نفسها تظهر مرة أخرى لحاوية Docker جديدة تمامًا (مستضافة في ECS خلف ALB) ، ووجدنا حلًا مختلفًا تمامًا (ولكن في الإدراك المتأخر ، كان يجب أن يكون واضحًا): تخصيص المزيد من الذاكرة للحاوية في CloudFormation نموذج.

لقد عانينا من هذه المشكلة العام الماضي ولم نعثر مطلقًا على سبب جذري لمسدس التدخين ، لكنني رصدته الليلة في حاوية جديدة ، ولاحظت أن الحاوية كانت تستهلك كل الذاكرة التي خصصناها. بمجرد أن ضاعفت التخصيص ، توقفت الحاويات عن إلقاء هذا الخطأ (حتى قبل أن أخصص أكثر مما ستستهلكه في النهاية):
https://github.com/hackoregon/civic-devops/issues/157

تواجه مشكلة مماثلة هنا. الشفرة بسيطة مثل

while true:
      sleep(10)

يمكن أن يؤدي إلى وفاة العامل (بدون هذا الرمز يكون نشرنا أمرًا طبيعيًا)
إنه أمر محير للغاية ، يجب أن يرسل b / c sleep نبضات قلب بالفعل.

أيضا قد تغيرت بالفعل إلى gevent ، لم يساعد. أتساءل إذا كان أي شخص لديه أي فكرة؟

إخراج العينة:
[2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:521) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:522) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:523) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:524) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:525) [2018-06-16 16:00:16 +0000] [524] [INFO] Worker exiting (pid: 524) [2018-06-16 16:00:16 +0000] [521] [INFO] Worker exiting (pid: 521) [2018-06-16 16:00:16 +0000] [523] [INFO] Worker exiting (pid: 523) [2018-06-16 16:00:16 +0000] [522] [INFO] Worker exiting (pid: 522) [2018-06-16 16:00:16 +0000] [525] [INFO] Worker exiting (pid: 525) [2018-06-16 16:00:17 +0000] [531] [INFO] Booting worker with pid: 531 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [136] [DEBUG] 1 workers [2018-06-16 16:00:17 +0000] [532] [INFO] Booting worker with pid: 532 [2018-06-16 16:00:17 +0000] [533] [INFO] Booting worker with pid: 533 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [534] [INFO] Booting worker with pid: 534 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [535] [INFO] Booting worker with pid: 535 [2018-06-16 16:00:17 +0000] [136] [DEBUG] 5 workers

آسف لتعكير المياه هنا ولكن أردت فقط مشاركة تجربتي ، فإن مجموعتي هي HTTP ELB > Nginx > gunicorn/gevent on EC2 ، يتم تشغيل العمليات باستخدام Circusd

كانت المشكلة التي وجدتها هي أنه بعد تجهيز تطبيق django الخاص بي باستخدام apm المرن ، ستبدأ فحوصات HTTP الصحية الخاصة بي في الفشل على الفور تقريبًا وسيصبح gunicorn غير مستجيب بعد بضع ثوانٍ.

لقد جربت عددًا قليلاً من المقاييس المرجعية المحلية wrk مقابل فحص الصحة الخاص بي ، كانت المزامنة تحصل على حوالي 300rps لـ 1-5 عمال ، لكن gevent ستحصل على 1rps. جلب إيقاف تشغيل apm gevent ما يصل إلى حوالي 50rps وزيادة مهملة للمزامنة.

لم ألاحظ أي استخدام غريب للذاكرة على valgrind ، عادةً حوالي 4 ميجابايت لجهاز gunicorn و 40 ميجابايت لكل عامل

على أي حال ، فإن تحديث gunicorn 19.6.0 > 19.9.0 و gevent 1.2.2 > 1.3.6 يمنحني فحص ELB الصحي الثابت مرة أخرى و ~ 300rps محليًا. لم أكن أقوم بتحديث gunicorn / gevent عن عمد حتى كان لدي بعض تسجيلات APM في مكانها ، ويبدو أن القيام بذلك قد دفع ببعض الصدفة. أعطى تحديث gevent أكبر دفعة ، وهذا أمر مفهوم ، ولكن يبدو أن تحديث gunicorn أضاف 10٪ أخرى أو نحو ذلك.

ألم تنظر إلى التغييرات بتفصيل كبير حتى الآن ، فربما يمكن للقائمين على الصيانة إلقاء الضوء على السبب المحتمل؟

على أي حال ، فإن تحديث gunicorn 19.6.0> 19.9.0 و gevent 1.2.2> 1.3.6 يمنحني فحص ELB الصحي الثابت مرة أخرى و 300 دورة في الثانية محليًا .... أعطى تحديث gevent أكبر دفعة

واو ، هذا رائع جدًا!

قضية ختامية. لا يوجد نشاط منذ فترة.

FWIW ، ما زلت أواجه هذه المشكلة benoitc : - \

Django 2.1.5.1 تحديث
جونيكورن 19.8.1
gevent 1.2.2
AKS 1.15.7 مع 5 عقد (معيار B2's - 2 vcores وذاكرة 2GB)
3 حاويات / حاويات رصيف ، كل منها يحتوي على:

    spec:
      containers:
        - name: web-container
          command: ["newrelic-admin"]
          args: [
              "run-program",
              "gunicorn",
              "--limit-request-field_size=16380", # limit also specified in nginx
              "--workers=3", # (2 x vcpu) + 1. vcpu < limit defined in resources
              "-k=gevent",
              "-b=0.0.0.0:8000",
              "ourapp.wsgi",
              "--timeout 60",
              "--log-level=debug",
            ]
          resources:
            requests:
              memory: "200Mi"
              cpu: "250m"
            limits:
              memory: "3000Mi"
              cpu: "2000m"

نفس المشكلة هنا مع EKS و Nginx و NLB.

salmicrosoftsinkr OK ولكن يرجى فتح قضية جديدة وتقديم أي سجلات لديك يمكن أن تساعدنا على الرقم ما يحدث. أيضا ماذا يفعل تطبيقك؟ هل لديك طلب طويل؟

واجهت نفس المشكلة على ECS Fargate ، لكنها كانت مرتبطة بإعدادات Keepalive / timeout غير الصحيحة في Docker / gunicorn.conf.py ، لقد كانت
ابق على قيد الحياة (غير محدد)
المهلة = 2

قبل إصلاحه يعمل بشكل جيد مع حاوية تعمل محليًا ، لكنه فشل في ECS Fargate ، فهو يعمل الآن بشكل صحيح في كلتا البيئتين.