Celery: توقف العامل عن الاستجابة وتوقف عن الاستجابة بعد فترة زمنية غير محددة (أحيانًا).

mvaled هل وجدت أي حل؟

لا. لكن اليوم ، عندما وصلت إلى العمل ، كانت زهرة تُظهر للعامل "غير المتصل" مرة أخرى بعد 2000 مهمة.

أنا أصوت لإبقاء هذا مفتوحا. ربما أجد القليل من الوقت لإجراء تحقيق أعمق.

لدي نفس المشكلة.

kombu = 4.0.2
celery = 4.0.2
amqp = 2.1.4
billiard = 33.5.0.2
redis = 2.10.5

بيئتي هي -c 16 و worker_max_tasks_per_child=1 .
أتساءل أن يحدث هذا عندما يبدو العامل مشغولاً.

مرحبا saorio ،

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

آسف للرد في وقت متأخر جدا.
مهمتي لا تستخدم الخيوط أو greenlets. العامل يعمل من قبل المشرف.

إذا كان بإمكانك تثبيت جميع الالتزامات الأخيرة من الفرع الرئيسي والتحقق؟

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

mvaled أي تحديث؟

مرحبًا dralley ،

لا شيء حتى الان. ومع ذلك ، فإن الخطأ يظهر من وقت لآخر. وصلت اليوم إلى العمل ووجدت أن عاملاً آخر (هذا لديه -c 3 ) معلق بعد 6000 وظيفة (3 أضعاف الحد الأقصى للمهمة لكل عامل).

لم أتمكن من نشر الرئيسي في خادم التدريج ، كما قلت سأفعل. سأحاول مرة أخرى اليوم.

رؤية مشكلة مماثلة على الكرفس == 4.0.2 و -c 2. ما عدا خاصتي معلقة على أنبوب TCP غير المرتبط / المتصل في أي مكان (ربما لإتقان العملية؟). تبدو الاتصالات في redis جيدة.
هل هذه قضية وسيط؟

لقد نشرت للتو في خادمنا المرحلي مع الكرفس في a6b3e2278ed38c153b07e38177794dd3d3e280af و kombu في celery / kombu @ dba85e2d9515b9ce202bd30e8690131aa055e6bf.

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

حسنًا ، لم يكن علي الانتظار طويلاً. اليوم ، في الخادم المرحلي مع الفرع "الرئيسي" أحصل على:

والشيء المضحك هو أن العامل الأول "غير المتصل" الذي تمت معالجته ليس مضاعفًا متكاملًا لـ 10 (الحد الأقصى للمهام لكل عامل). تبقى الأعراض الأخرى:

$ strace -p 25614  # the cdr-1<strong i="9">@stage2</strong> MainProcess

strace: Process 25614 attached
recvfrom(28, 

لا شيء يحدث هنا. يظهر lsof نفس الشيء:

[celeryd: 25614 mercurio    0r  FIFO       0,8      0t0 321516134 pipe
[celeryd: 25614 mercurio    1w  FIFO       0,8      0t0 321516135 pipe
[celeryd: 25614 mercurio    2w  FIFO       0,8      0t0 321516136 pipe
[celeryd: 25614 mercurio    3u  0000       0,9        0      4073 [eventpoll]
[celeryd: 25614 mercurio    4u  0000       0,9        0      4073 [eventpoll]
[celeryd: 25614 mercurio    5u  0000       0,9        0      4073 [eventpoll]
[celeryd: 25614 mercurio    6r  FIFO       0,8      0t0 321517058 pipe
[celeryd: 25614 mercurio    7w  FIFO       0,8      0t0 321517058 pipe
[celeryd: 25614 mercurio    8r  FIFO       0,8      0t0 321517059 pipe
[celeryd: 25614 mercurio    9w  FIFO       0,8      0t0 321517059 pipe
[celeryd: 25614 mercurio   10r   CHR       1,9      0t0   3582641 /dev/urandom
[celeryd: 25614 mercurio   11r   CHR       1,9      0t0   3582641 /dev/urandom
[celeryd: 25614 mercurio   12r  FIFO       0,8      0t0 323120452 pipe
[celeryd: 25614 mercurio   13u  0000       0,9        0      4073 [eventpoll]
[celeryd: 25614 mercurio   14u  sock       0,6      0t0 323094902 can't identify protocol
[celeryd: 25614 mercurio   15u  sock       0,6      0t0 323094909 can't identify protocol
[celeryd: 25614 mercurio   16r   CHR       1,9      0t0   3582641 /dev/urandom
[celeryd: 25614 mercurio   17u  sock       0,6      0t0 323094922 can't identify protocol
[celeryd: 25614 mercurio   18u  0000       0,9        0      4073 [eventpoll]
[celeryd: 25614 mercurio   19u  0000       0,9        0      4073 [eventpoll]
[celeryd: 25614 mercurio   20u  sock       0,6      0t0 321517162 can't identify protocol
[celeryd: 25614 mercurio   21u  sock       0,6      0t0 323094894 can't identify protocol
[celeryd: 25614 mercurio   22u  sock       0,6      0t0 323094887 can't identify protocol
[celeryd: 25614 mercurio   23u  sock       0,6      0t0 323094929 can't identify protocol
[celeryd: 25614 mercurio   24u  sock       0,6      0t0 323094936 can't identify protocol
[celeryd: 25614 mercurio   25u  sock       0,6      0t0 323094943 can't identify protocol
[celeryd: 25614 mercurio   26u  sock       0,6      0t0 323094950 can't identify protocol
[celeryd: 25614 mercurio   27r  FIFO       0,8      0t0 323120452 pipe
[celeryd: 25614 mercurio   28u  IPv4 323120457      0t0       TCP localhost.localdomain:55904->localhost.localdomain:6379 (ESTABLISHED)

fd 28 هو اتصال redis.

يظهر نفس النمط للعملية الرئيسية "الإخطارات الافتراضية 3".

تتراكم وظائف قائمة الانتظار "odoo-10.0.cdr" ، التي يستهلكها عامل "cdr" بشكل حصري:

$ redis-cli -n 9 llen 'odoo-10.0.cdr'
(integer) 347

إعادة تشغيل العمال تجعلهم يعملون ، ويقل التراكم:

$ redis-cli -n 9 llen 'odoo-10.0.cdr'
(integer) 257

أرى أيضًا هذه المشكلة مع الكرفس 4.1.0. أي تحديث هنا؟

لقد غيرت عنوان المشكلة لأنها لا تحدث الآن على حدود المهام القصوى لكل طفل. اليوم وجدت العامل غير متصل بالإنترنت بعد 11727 وظيفة.

mvaled هل جربت أحدث الإصدارات (4.2.0rc1 أو 4.2.0rc2)؟

لنجرب 4.2rc2 وجميع التبعيات من جيثب ماستر

auvipy ما هو فرع 4.2rc2؟ كما قلت من قبل ، قمت بنشر خادم مرحلي به فرع "رئيسي" لكل من الكرفس والكومبو وقمت بإعادة إنتاج الخطأ هناك أيضًا.

mvaled pip install -U celery

مرحبًا WoaDmulL لن يعمل ذلك بالنسبة لي: أستخدم buildout لنشر هذا التطبيق. يمكنني تثبيت رقم الإصدار ، رغم ذلك.

ومع ذلك ، لاحظ أنك ستحتاج إلى تنفيذ pip install --pre -U celery لتثبيت إصدار ما قبل الإصدار.

ولكن منذ ذلك الحين ، يمكن تكرار الخطأ في الفرع الرئيسي الذي أفترض أنه لا يزال موجودًا في 4.2.0rc2. على أي حال ، سأحاول مع tarball قبل الإصدار.

هل يمكنك تثبيت kombu ، pyamqp من Master أيضًا؟ استخدم جميع الرموز من السيد وأخبرنا

نشر فصل مرحلي باستخدام 3fe5a20ca655aa3aeed60205b39ede2a21845df0 ؛ كرفس / كومبو @ 0f6ef8c90b32ca4fbefestivalf2262efea343a4e5bc؛ والكرفس / py-amqp @ 2e145d2edf9865a1dfb79ea4d087a28b3c9e969b.

دعنا ننتظر بضع ساعات لنرى ما إذا كان العامل معلقًا.

حسنًا ، للأسف ، مع تلك الالتزامات ، يفشل العمال في البدء:

AttributeError: async
  File "srv/mercurio/src/xhg/bin/xoeuf", line 126, in <module>
    sys.exit(xoeuf.cli.server.server())
  File "xoeuf/cli/server.py", line 28, in server
    main(default=DEFAULT_COMMAND)
  File "xoutil/cli/app.py", line 44, in main
    sys.exit(cmd().run(args))
  File "odoo/cli/celery.py", line 44, in run
    _main(argv=['celery', ] + cmdargs)
  File "celery/bin/celery.py", line 322, in main
    cmd.execute_from_commandline(argv)
  File "celery/bin/celery.py", line 484, in execute_from_commandline
    super(CeleryCommand, self).execute_from_commandline(argv)))
  File "celery/bin/base.py", line 275, in execute_from_commandline
    return self.handle_argv(self.prog_name, argv[1:])
  File "celery/bin/celery.py", line 476, in handle_argv
    return self.execute(command, argv)
  File "celery/bin/celery.py", line 408, in execute
    ).run_from_argv(self.prog_name, argv[1:], command=argv[0])
  File "celery/bin/worker.py", line 223, in run_from_argv
    return self(*args, **options)
  File "celery/bin/base.py", line 238, in __call__
    ret = self.run(*args, **kwargs)
  File "celery/bin/worker.py", line 257, in run
    **kwargs)
  File "celery/worker/worker.py", line 101, in __init__
    self.setup_instance(**self.prepare_args(**kwargs))
  File "celery/worker/worker.py", line 124, in setup_instance
    self.should_use_eventloop() if use_eventloop is None
  File "celery/worker/worker.py", line 243, in should_use_eventloop
    self._conninfo.transport.implements.async and
  File "kombu/transport/base.py", line 125, in __getattr__
    raise AttributeError(key)

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

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

يمكنك الحصول على التفاصيل هنا في التعليق الأخير https://github.com/celery/celery/issues/4500

أواجه نفس مشكلة mvaled باستخدام إصدار الكرفس == 4.2.0rc3

Traceback (آخر مكالمة أخيرة):
ملف "/usr/local/lib/python3.5/site-packages/kombu/transport/base.py" ، السطر 123 ، في __getattr__
العودة الذاتية [مفتاح]
KeyError: "غير متزامن"

أثناء معالجة الاستثناء أعلاه ، حدث استثناء آخر:

Traceback (آخر مكالمة أخيرة):
ملف "/ usr / local / bin / celery" ، السطر 11 ، في
sys.exit (main ())
ملف "/usr/local/lib/python3.5/site-packages/celery/__main__.py" ، السطر 16 ، بشكل رئيسي
_الأساسية()
ملف "/usr/local/lib/python3.5/site-packages/celery/bin/celery.py" ، السطر 322 ، بشكل رئيسي
cmd.execute_from_commandline (argv)
ملف "/usr/local/lib/python3.5/site-packages/celery/bin/celery.py" ، السطر 484 ، في execute_from_commandline
سوبر (CeleryCommand، self). execute_from_commandline (argv)))
ملف "/usr/local/lib/python3.5/site-packages/celery/bin/base.py" ، السطر 275 ، في execute_from_commandline
إرجاع self.handle_argv (self.prog_name، argv [1:])
ملف "/usr/local/lib/python3.5/site-packages/celery/bin/celery.py" ، السطر 476 ، في handle_argv
return self.execute (الأمر ، argv)
ملف "/usr/local/lib/python3.5/site-packages/celery/bin/celery.py" ، السطر 408 ، قيد التنفيذ
) .run_from_argv (self.prog_name، argv [1:]، الأمر = argv [0])
ملف "/usr/local/lib/python3.5/site-packages/celery/bin/worker.py" ، السطر 223 ، في run_from_argv
العودة الذاتية ( أرغس ، خيارات)ملف "/usr/local/lib/python3.5/site-packages/celery/bin/base.py" ، السطر 238 ، في __call__ret = self.run ( args ، * kwargs)ملف "/usr/local/lib/python3.5/site-packages/celery/bin/worker.py" ، السطر 257 ، قيد التشغيل* kwargs)
ملف "/usr/local/lib/python3.5/site-packages/celery/worker/worker.py" ، السطر 101 ، في __init__
self.setup_instance (self.prepare_args (** kwargs))
ملف "/usr/local/lib/python3.5/site-packages/celery/worker/worker.py" ، السطر 124 ، في setup_instance
self.should_use_eventloop () إذا كانت use_eventloop هي بلا
ملف "/usr/local/lib/python3.5/site-packages/celery/worker/worker.py" ، السطر 243 ، في should_use_eventloop
self._conninfo.transport.implements.async و
ملف "/usr/local/lib/python3.5/site-packages/kombu/transport/base.py" ، السطر 125 ، في __getattr__
رفع AttributeError (مفتاح)
AttributeError: غير متزامن

يؤدي الرجوع إلى إصدار kombu 4.0.2 إلى إصلاح المشكلة. كانت المشكلة الالتزام https://github.com/celery/celery/commit/ed0130cad13ffb08256243ff87254abe00b3c565
الذي قام بتحديث متطلبات الإصدار 4.1.0 من الكرفس إلى kombu 4.2.0. الرجاء auvipy إصلاحه!

هل يمكنك محاولة 4.1.1 قد تنتظر أيضًا 4.2rc4

العدد 4500 مغلق الآن. سأحاول أولاً مع الكرفس 4.1.1 ، وإذا كان الخطأ لا يزال موجودًا ، فسأحاول مع السيد مرة أخرى.

مع الكرفس 4.1.1 و kombu 4.2.0 ، أصبح الخطأ أحد العمال غير مستجيب بعد 50 وظيفة (مع تعيين الحد الأقصى للوظائف لكل عامل على 10).

سأقوم باختبار مع "سيد".

يرجى إعلامنا بأحدث حل لك حول هذه المشكلة mvaled with celery 4.2rc4

أنا أقوم بنشر خادم مرحلي باستخدام الكرفس 4.2rc4.

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

مثير للإعجاب! حتى تتحسن؟

أنا حقًا متشكك حيال ذلك ، ولكن بعد 24 ساعة من العمل يظل جميع العمال متصلين بالإنترنت. auvipy ما رأيك؟ هل هناك أي التزامات تلامس (ربما) المكونات المعنية؟

الكالينجيون .. صعب للغاية ولكن قد يستغرق بعض الوقت لاكتشافهم

وبعد 2110 وظيفة سقط عامل:

وفقًا للتراكم في قائمة الانتظار ، فقد تم إيقاف العمل بحوالي 8 ساعات بالفعل:

$ redis-cli -n 9  llen 'odoo-10.0.cdr'
(integer) 484

قد يكون هذا الخطأ مرتبطًا بـ https://github.com/celery/celery/issues/3898. بالمناسبة ، لقد لاحظت نفس السلوك عند فشل المهمة مع انتهاء المهلة (إذا تم تحديد time_limit). بعد إزالة hiredis كل شيء يعمل بشكل صحيح. هل قمت بتثبيت hiredis؟

لدي hiredis مثبت. سأحاول بدونها.

سأكون مهتمًا بما إذا كان mvaled لا يزال لديه نفس المشكلات حتى بدون hiredis . أتوقع ، أو ربما آمل ، أنه لا يزال يرى نفس المشكلة لأنها تعكس تجربتي الخاصة بما في ذلك مع Celery 4.2 على الرغم من أننا على منصات مختلفة تمامًا (أنا على FreeBSD أدير عمليات الكرفس الخاصة بي في السجن. إذا قمت بتشغيل redis داخل السجن ، لا أرى هذه المشكلات خلال الفترة القصيرة التي تركتها تعمل فيها والتي أشارت إلى مشكلة في الشبكة ولكن ليس لدي أي حظ في تعقب ذلك.)

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

لقد قمت للتو بإعادة نشر الخادم المرحلي بدون hiredis. لننتظر ونرى.

بالمناسبة؛ أنا أستخدم الإصدار 4.2.0 الذي تم إصداره مؤخرًا.

نأمل للأفضل

... خطط للأسوأ ، إذًا ستكون كل مفاجآتك ممتعة :)

طار 21 ساعة وجميع العمال ما زالوا على قيد الحياة. لذا ، ربما موظفون ... غدًا سأتحقق مرة أخرى.

يتطلع

حسنًا ، 23 ساعة أخرى مع العمال على قيد الحياة. فهل نغلق هذه القضية ونتعامل معها في # 3898؟

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

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