Sidekiq يستمر في إعادة التشغيل، كيف يمكن استكشاف الأخطاء وإصلاحها؟

مرحباً،

لقد كنا ندير خادم Discourse متعدد المجالات مكون من حاويتين لمدة 4 سنوات تقريبًا ونستضيف حوالي 20 مجالًا. أجرينا تحديثات منتظمة بنجاح. ومع ذلك، لاحظنا في بداية أكتوبر (بدءًا من حوالي 8-10 أكتوبر)، ربما بعد تحديث Discourse، أن رسائل البريد الإلكتروني للتسجيل لم يتم إرسالها. لاحظنا أن مهمة sidekiq لا تعمل، وأن Sidekiq يستمر في إعادة التشغيل.

الاختلاف الوحيد مع عمليات الترحيل العادية التي نجريها هو أنه كان عليّ تعديل جميع قواعد بيانات Postgres يدويًا لتفعيل أحدث امتداد vector؛ يبدو أن نص الترقية يقوم بذلك فقط على قاعدة البيانات الرئيسية discourse.

الأعراض:

  1. تظهر السجلات أن Sidekiq يعاد تشغيله كل بضع ثوانٍ

  1. يرتبط إعادة التشغيل برسالة الخطأ التالية:
/var/www/discourse/lib/demon/sidekiq.rb:31:in `heartbeat_check'
config/unicorn.conf.rb:131:in `block (2 levels) in reload'
E, [2025-11-01T11:56:05.989645 #67] ERROR -- : reaped #<Process::Status: pid 6534 SIGKILL (signal 9)> worker=unknown
I, [2025-11-01T11:56:41.468169 #7038]  INFO -- : Loading Sidekiq in process id 7038
W, [2025-11-01T11:57:20.944092 #67]  WARN -- : Process would not terminate cleanly, force quitting. pid: 7038 Demon::Sidekiq
/var/www/discourse/lib/demon/base.rb:94:in `restart'
/var/www/discourse/lib/demon/sidekiq.rb:40:in `block in heartbeat_check'
/var/www/discourse/lib/demon/sidekiq.rb:31:in `each'
/var/www/discourse/lib/demon/sidekiq.rb:31:in `heartbeat_check'
  1. يبدو أن “عرض sidekiq” لا يعالج المهام

  1. يعرض واجهة المستخدم بعض التحذيرات بأن sidekiq لا يعمل بشكل صحيح: “لم يتم إجراء فحص للتحديثات. تأكد من أن Sidekiq قيد التشغيل.”

إليك ما جربته:

  • إعادة البناء (لا يوجد خطأ)
  • مسح قائمة انتظار Redis (يعمل، لوحة تحكم Sidekiq تعود إلى الصفر ولكن المهام لا تزال لا تتم معالجتها)
  • التحقق من إصدار redis في حاوية البيانات (إصدار redis: 7.0.15)
  • التحقق مما إذا كان Sidekiq متوقفًا مؤقتًا (ليس كذلك)
  • تصفح السجلات في shared/web-only/log، لكنني لم أتمكن من العثور على أي شيء ذي صلة، على الرغم من أن الإشارات الإضافية مرحب بها!
  • حاولت تفعيل سجلات Sidekiq عن طريق تعيين DISCOURSE_LOG_SIDEKIQ: 1 في web_only.yml متبوعًا بـ ./launcher stop web_only && ./launcher destroy web_only && ./launcher start web_only، ويظهر السجل فقط رسائل نجاح مثل:
{"hostname":"forum-web-only","pid":12961,"database":"chatonnade","job_id":null,"job_name":"Jobs::DiscourseAutomation::StalledWikiTracker","job_type":"scheduled","opts":"{}","status":"success","live_slots_start":1298445,"duration":0.04405494895763695,"sql_duration":0.03392060892656446,"sql_calls":1,"redis_duration":0,"redis_calls":0,"net_duration":0,"net_calls":0,"live_slots_finish":1299663,"live_slots":1218,"@timestamp":"2025-11-01T12:17:32.561+00:00"}

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

شكراً جزيلاً!

لاحظت الشيء نفسه ولكن ليس بنفس التكرار. لقد كان يعمل بشكل جيد لسنوات ولكن في الآونة الأخيرة أراه يحدث مرة واحدة تقريبًا في الشهر. لقد ضاعفت ذاكرة الوصول العشوائي (RAM) على المثيل العام الماضي لمواكبة ترقيات discourse.

Message

فشل اختبار نبضات القلب لـ Sidekiq برقم 2087، وإعادة التشغيل

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:218:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:217:in `map'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:217:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.4/lib/active_support/broadcast_logger.rb:129:in `warn'
/var/www/discourse/lib/demon/sidekiq.rb:39:in `block in heartbeat_check'
/var/www/discourse/lib/demon/sidekiq.rb:31:in `each'
/var/www/discourse/lib/demon/sidekiq.rb:31:in `heartbeat_check'
config/unicorn.conf.rb:131:in `block (2 levels) in reload'
إعجاب واحد (1)

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

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