توقف Sidekiq عن العمل (على وظيفة BotInput?)

في الأسبوع الماضي، رأينا ثلاث مثيلات من Sidekiq في منتديات مختلفة عالقة. لم يكن هناك شيء مميز يحدث، بل كان Sidekiq لا يعالج أي عمل ويعرض 5 من أصل 5 مهام قيد المعالجة.

أحد الأشياء المثيرة للاهتمام التي كانت مشتركة بينهم جميعًا هو وجود مهمة BotInput واحدة بالغة الأهمية ضمن المهام. الآن هذه مهمة شائعة جدًا، لكنها لا تزال تبرز.

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

هل لدى أي شخص أي فكرة عن كيفية تتبع ما يحدث هنا؟

إعجاب واحد (1)

لقد واجهنا أيضًا توقفات كهذه، ولا يستطيع مضيفنا معرفة سبب ذلك.

[quote=“Richard - Communiteq, post:1, topic:352661, username:RGJ”]كان الأمر مجرد أن Sidekiq لم يكن يعالج أي عمل وكان يُظهر 5 من أصل 5 وظائف قيد المعالجة.
[/quote]

هل لديك لقطة شاشة لما تراه في لوحة التحكم؟

إذا استطعت، يرجى محاولة إرسال إشارة TTIN إلى عملية Sidekiq وتقديم تتبع الخلفية هنا.

إعجاب واحد (1)

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

sidekiq-clean.txt (35.8 KB)

ملخص السجلات

[default] Thread TID-1ow77
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/cli.rb:199:in `backtrace'
--
[default] Thread TID-1o1jr
[default] /var/www/discourse/lib/demon/base.rb:234:in `sleep'
--
[default] Thread TID-1o1j7
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/connection/ruby.rb:57:in `wait_readable'
--
[default] Thread TID-1o1j3
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/timer_thread.rb:130:in `sleep'
--
[default] Thread TID-1o1ij AR Pool Reaper
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool/reaper.rb:49:in `sleep'
--
[default] Thread TID-1o1hj
[default] internal:thread_sync:18:in `pop'
--
[default] Thread TID-1o1gz AR Pool Reaper
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/abstract/connection_pool/reaper.rb:49:in `sleep'
--
[default] Thread TID-1o1gv
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:18:in `sleep'
--
[default] Thread TID-1o1gb
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler/manager.rb:32:in `sleep'
--
[default] Thread TID-1otmb
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otkn
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otjz
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1otif
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1othr
[default] /var/www/discourse/app/models/top_topic.rb:8:in `refresh_daily!'
--
[default] Thread TID-1o1fb
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mini_scheduler-0.18.0/lib/mini_scheduler.rb:80:in `sleep'
--
[default] Thread TID-1o1er
[default] /var/www/discourse/lib/mini_scheduler_long_running_job_logger.rb:87:in `sleep'
--
[default] Thread TID-1o1en heartbeat
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-6.5.12/lib/sidekiq/launcher.rb:76:in `sleep'
--
[default] Thread TID-1o1e3 scheduler
[default] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/connection_pool-2.5.0/lib/connection_pool/timed_stack.rb:79:in `sleep'
--
[default] Thread TID-1ot4n processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot67 processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot8j processor
[default] /var/www/discourse/app/models/email_log.rb:58:in `unique_email_per_post'
--
[default] Thread TID-1ot5n processor
[default] /usr/local/lib/ruby/3.3.0/bundled_gems.rb:74:in `require'
--
[default] Thread TID-1ot6b processor
[default] /var/www/discourse/lib/distributed_mutex.rb:5:in `<main>'
--
[default] Thread TID-1o0kn final-destination_resolver_thread
[default] internal:thread_sync:18:in `pop'
--
[default] Thread TID-1o0k3 Timeout stdlib thread
[default] internal:thread_sync:18:in `pop'

هل أتيحت لك الفرصة يا @tgxworld لإلقاء نظرة على تتبع المكدس؟

لقد كنت أواجه مشاكل في Sidekiq منذ ترقية منتدى قبل شهر. ما هو الأمر الذي تستخدمه لإعادة تشغيل Sidekiq؟ هل هو مجرد sv restart sidekiq؟

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

إعجاب واحد (1)

أرى هذا في الأيام القليلة الماضية. في النهاية تتوقف جميع المهام عن العمل. في السابق كنت أعيد التشغيل، ولكن هل من الآمن حذف قائمة الانتظار الحرجة؟ هل هي قائمة انتظار Redis؟

أنا محدث على 3.5.0.beta1-dev.

مجرد تخمين، ولكن في بعض الأحيان عندما أتحدث مع الروبوت يتوقف عن الاستجابة، لذا أقوم بتحديث الصفحة أو أستسلم. ربما تترك تلك الحالات مهمة معلقة؟

إعجاب واحد (1)

هذه المهام غير متزامنة لذا لن تعرف حتى أنك فعلت ذلك.

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

لا، ستفقد جميع المهام الأخرى المعلقة أيضًا.

الطريقة الأسهل والأكثر أمانًا هي sv reload unicorn من داخل الحاوية.

إعجاب واحد (1)

ليس الأمر كذلك في منتدانا. الذكاء الاصطناعي مرئي فقط للموظفين، وقد أكدت أن أي من الموظفين لا يستخدمونه.

لقد أوقفت تفعيل الذكاء الاصطناعي مؤقتًا.

BotInput هو مهمة من Discourse Narrative Bot (المعروف أيضًا باسم Discobot)، وليس الروبوت الذكاء الاصطناعي.

آه. لقد كنت أستخدم واجهة برمجة التطبيقات بكثافة، باسم المستخدم discobot.

لقد ألقيت نظرة على تتبعات المكدس وتشير جميعها إلى وجود مشكلة في السطر التالي:

لست متأكدًا تمامًا من سبب تسبب هذا السطر في حدوث مشكلات، ولكنه سطر غير ضروري، لذا فقد قمت بإزالته في:

@RGJ هل لديك Rails.application.config.eager_load مضبوطًا على تعطيل لسبب ما؟ :thinking:

إعجابَين (2)

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

  • عندما تتعطل إحدى تلك الحالات (نعرف حينها أن هذا لم ينجح)
  • يوم الجمعة إذا لم تتعطل أي منها (يمكننا حينها البدء في افتراض أنه كان الحل)

لا، لم أعبث بذلك.

لكن شخصًا ما فعل…

Rails.autoloaders.main.do_not_eager_load(config.root.join("lib"))

في Blaming discourse/config/application.rb at main · discourse/discourse · GitHub

3 إعجابات

@loic هل تتذكر لماذا لا نقوم بتحميل مسبق لدليل lib حتى في بيئة الإنتاج؟

إعجاب واحد (1)

بينما كانت المشكلات تحدث هذا الأسبوع، إلا أنها لم تحدث في الحالات الثلاث التي أزلنا فيها سطر require هذا، لذلك أعتقد أنه يمكننا افتراض بأمان أن هذا هو الجاني :tada: . شكرًا لك على اكتشاف ذلك @tgxworld ، لم أكن لأجده أبدًا.

هل يمكنك إعادة تطبيق هذا الإصلاح على الإصدار المستقر؟

إعجاب واحد (1)

يتعلق الأمر بما هو موضح هنا (عندما قمنا بالترقية إلى Rails 7.1): Upgrading Ruby on Rails — Ruby on Rails Guides

لا أتذكر المشكلة بالضبط، لكننا في الواقع احتفظنا بالسلوك السابق، واضطررنا إلى طلب الأشياء من lib.