<p>مهلة العامل الناقد gunicorn</p>

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

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

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

أنا أواجه نفس المشكلة بالضبط.
جونيكورن 19.7.1
جيفينت 1.2.1
بايثون 3.5.3
قيد التشغيل في Docker ، الصورة مستوحاة من "

jseaidou إنها مهلة غير عادية بمعنى أن الحكم يتفاعل معها. إنه أمر بالغ الأهمية لأنه لا ينبغي أن يحدث في العادة.

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

كيف يمكنني إعادة إظهار المشكلة؟

saabeilin نفس الشيء ^ ^

أرى نفس الشيء: العمال يتوقفون عن العمل حتى عند عدم تقديم أي طلبات. كل ما فعلته هو إطلاق الحاوية الخاصة بي على AWS ECS.

[2017-06-27 20:41:56 +0000] [1] [DEBUG] Current configuration:
proxy_protocol: False
worker_connections: 1000
statsd_host: None
max_requests_jitter: 0
post_fork: <function post_fork at 0x7f6bbc3f1938>
errorlog: -
enable_stdio_inheritance: False
worker_class: sync
ssl_version: 2
suppress_ragged_eofs: True
syslog: False
syslog_facility: user
when_ready: <function when_ready at 0x7f6bbc3f1668>
pre_fork: <function pre_fork at 0x7f6bbc3f17d0>
cert_reqs: 0
preload_app: False
keepalive: 2
accesslog: -
group: 0
graceful_timeout: 30
do_handshake_on_connect: False
spew: False
workers: 4
proc_name: None
sendfile: None
pidfile: None
umask: 0
on_reload: <function on_reload at 0x7f6bbc3f1500>
pre_exec: <function pre_exec at 0x7f6bbc3f1ed8>
worker_tmp_dir: None
limit_request_fields: 100
pythonpath: None
on_exit: <function on_exit at 0x7f6bbc3f7758>
config: None
logconfig: None
check_config: False
statsd_prefix:
secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
reload_engine: auto
proxy_allow_ips: ['127.0.0.1']
pre_request: <function pre_request at 0x7f6bbc3f70c8>
post_request: <function post_request at 0x7f6bbc3f71b8>
forwarded_allow_ips: ['127.0.0.1']
worker_int: <function worker_int at 0x7f6bbc3f1c08>
raw_paste_global_conf: []
threads: 1
max_requests: 0
chdir: /opt/app
daemon: False
user: 0
limit_request_line: 4094
access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
certfile: None
on_starting: <function on_starting at 0x7f6bbc3f1398>
post_worker_init: <function post_worker_init at 0x7f6bbc3f1aa0>
child_exit: <function child_exit at 0x7f6bbc3f7320>
worker_exit: <function worker_exit at 0x7f6bbc3f7488>
paste: None
default_proc_name: app:app
syslog_addr: udp://localhost:514
syslog_prefix: None
ciphers: TLSv1
worker_abort: <function worker_abort at 0x7f6bbc3f1d70>
loglevel: DEBUG
bind: ['0.0.0.0:5005']
raw_env: []
initgroups: False
capture_output: False
reload: False
limit_request_field_size: 8190
nworkers_changed: <function nworkers_changed at 0x7f6bbc3f75f0>
timeout: 30
keyfile: None
ca_certs: None
tmp_upload_dir: None
backlog: 2048
logger_class: gunicorn.glogging.Logger
[2017-06-27 20:41:56 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-06-27 20:41:56 +0000] [1] [DEBUG] Arbiter booted
[2017-06-27 20:41:56 +0000] [1] [INFO] Listening at: http://0.0.0.0:5005 (1)
[2017-06-27 20:41:56 +0000] [1] [INFO] Using worker: sync
[2017-06-27 20:41:56 +0000] [8] [INFO] Booting worker with pid: 8
[2017-06-27 20:41:57 +0000] [9] [INFO] Booting worker with pid: 9
[2017-06-27 20:41:57 +0000] [10] [INFO] Booting worker with pid: 10
[2017-06-27 20:41:57 +0000] [12] [INFO] Booting worker with pid: 12
[2017-06-27 20:41:57 +0000] [1] [DEBUG] 4 workers
[2017-06-27 20:42:15 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:15 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-06-27 20:42:46 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-06-27 20:42:46 +0000] [12] [INFO] Worker exiting (pid: 12)
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 3 workers
[2017-06-27 20:42:46 +0000] [24] [INFO] Booting worker with pid: 24
[2017-06-27 20:42:46 +0000] [25] [INFO] Booting worker with pid: 25
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 4 workers

لا يحدث هذا عند التشغيل محليًا. : - /

يبدو أن التبديل إلى العمال gevent قد حل المشكلة بالنسبة لي. ¯ \ _ (ツ) _ / ¯

تكرار # 1194 ، على ما أعتقد.

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

gunicorn - daemon - العمال 2 - المهلة 120 - ربط 127.0.0.1:4000 --pid /var/run/mshc_admin.pid --user danilovskoe --group danilovskoe --chdir / home / danilovskoe / mshc2 / src / flask / --env MSHC_PRODUCTION = / etc / monit / mshc.config.py admin_ gunicorn: التطبيق

مهلة 30 ثانية
طلب الحصول عليها

أوبونتو 16.04.2018
قارورة 0.12.2
Python 3.6.3 (افتراضي ، 4 أكتوبر 2017 ، 02:55:45)
[GCC 5.4.0 20160609] على لينكس
gunicorn (الإصدار 19.7.1)

التقيت مع المتاعب.

فقط بعد بدء التطبيق ، يعمل. ولكن فقط في حالة وجود طلب ، سيتم تشغيل [CRITICAL] WORKER TIMEOUT . على سبيل المثال،

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

CentOS: 6.7
Python: 3.6.3
Gevent: 1.2.2
Greenlet: 0.4.9
Gunicorn: 19.7.1

RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

عندما قمت بتحويل فئة العامل إلى eventlet ، هذا ،
gunicorn --worker-class eventlet --log-level debug --bind 0.0.0.0:8080 app ،
لا بأس.

ملاحظة: يعمل تطبيقي على المضيف الفعلي ، لا على المضيف الظاهري ولا المضيف السحابي.

تحديث:

لذا أعتقد أن هذا هو السؤال عن العامل الجهدي أو العامل الجاد.

هناك تقارير حول هذه المسألة gevent حل المشكلة ومنع التسبب في المشكلة. لا أستطيع تحديد السبب الجذري هنا. قد تكون بعض التقارير مماثلة للرقم 1194 ، لكن البعض الآخر قد لا يكون كذلك.

إذا كان بإمكان أي شخص مشاركة الحد الأدنى من الحالات للتكاثر ، فسيكون ذلك مفيدًا.

لست متأكدًا من أنها نفس المشكلة بالتأكيد ، ولكن يمكنني إعادة إنتاج هذا بنسبة 100 ٪ من الوقت باستخدام Virtualbox مع الإعداد التالي:

المضيف: Windows 10
الضيف: أوبونتو 16.04
جونيكورن: 19.7.1

أقوم بإعادة توجيه TCP: 8000 بين المضيف والضيف عبر اتصال NAT الافتراضي. باستخدام عامل sync ، فإن أي طلبات على المضيف لـ localhost:8000 تتسبب في ظهور هذه الأخطاء في السجل ، ولكن إذا قمت بإجراء نفس الطلبات على الضيف ، فسيكون السجل واضحًا. التبديل إلى --worker-class eventlet يزيل التتبع.

أقدر أن Virtualbox بُعد مختلف تمامًا ، لكنه يبدو مشابهًا جدًا لما تم وصفه أعلاه ، وهو قابل للتكرار باستمرار (بالنسبة لي على الأقل).

أرى أن هذا يحدث مع التحميلات البطيئة. أثناء التحميل (إلى موقع Django) إذا انقضت مهلة العامل ، يموت التحميل.

lordmauve إذا كنت تستخدم عامل المزامنة المتوقع. الطلبات الطويلة ستمنع العامل وفي النهاية سيقتله الحكم. يمكنك استخدام نوع عامل مختلف إذا كنت تتوقع نجاح الطلبات الطويلة.

لأي شخص يقرأ هذا الموضوع ، يرجى إعادة الفتح مع الحد الأدنى من الحالات لإعادة إنتاجها. لا يمكنني رؤية أي تحقيق نظيف لمتابعة هنا. بالنسبة لحالة AWS / ECS ، ما زلت أترك # 1194 مفتوحًا حتى يمكنني اختبار التكوينات التي أدرجتها (https://github.com/benoitc/gunicorn/issues/1194#issuecomment-371250650).

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

كنت أواجه هذه المشكلة عندما حاولت نشر تطبيقي باستخدام Docker Swarm وأدركت أنني أقوم بتحديد الموارد منخفضة جدًا للتطبيق. زيادة الموارد يحل المشكلة بالنسبة لي

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

أعتقد أن هذا ليس خطأ ، فقط طريقة تكوين تطبيقاتنا

jseaidou إنها مهلة غير عادية بمعنى أن الحكم يتفاعل معها. إنه أمر بالغ الأهمية لأنه لا ينبغي أن يحدث في العادة.

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

كيف يمكنني إعادة إظهار المشكلة؟

saabeilin نفس الشيء ^ ^

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