Sidekiq تواجه الكثير من الأخطاء والمهام المعلقة

الدعم
1

لقد ظهرت لنا بعض النصائح في وحدة تحكم المسؤول بخصوص مهام Sidekiq المعلقة - لدينا ما يقرب من 200,000 مهمة معلقة، ولسنا متأكدين من كيفية حل المشكلة. نحن نستخدم الإصدار 3.2.0.

جميع المهام موجودة في قائمة الانتظار ultra_low، وتبدو وكأنها المهمة Jobs::ProcessPost. يبدو أنها جميعًا مشابهة لهذا:

	[{"bypass_bump"=>true, "cooking_options"=>nil, "new_post"=>false, "post_id"=>729508, "skip_pull_hotli... 
{"bypass_bump"=>true, "cooking_options"=>nil, "new_post"=>false, "post_id"=>729508, "skip_pull_hotlinked_images"=>false, "current_site_id"=>"default"}

كيف يمكننا معالجة هذه المهام، وكيف نفعل ذلك بطريقة تضمن عدم تأثيرها بشكل كبير على الأداء (أم أن ذلك حتمي)؟

إعجابَين (2)
2

قبل يومين، كان العدد حوالي 195 ألفًا؛ والآن ارتفع إلى 211 ألفًا. يمكن حقًا الاستعانة ببعض النصائح حول ما يجب النظر فيه وكيفية حل هذه المشكلة.

لقد لاحظنا 5 مهام ميتة تبدو كالتالي (تم إخفاء عناوين IP):

Jobs::HandledExceptionWrapper: Wrapped Errno::ENETUNREACH: Failed to open TCP connection to x.x.x.x:443 (Network is unreachable - connect(2) for "x.x.x.x" port 443)

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

إعجابَين (2)
3

تمت إضافة 7000 وظيفة أخرى إلى قائمة الانتظار في الساعات الـ 23 الماضية تقريبًا.

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

الـ 7000 وظيفة المضافة لا تتوافق مع عدد المنشورات الجديدة التي تلقيناها في اليوم الماضي، لذلك لست متأكدًا مما يدفع هذا على الإطلاق.

ما هي المعلومات الأخرى التي قد تكون مفيدة لحل هذه المشكلة؟

إعجابَين (2)
4

لا يمكنني المساعدة، إلا باقتراح أن المزيد من الردود والمزيد من الإعجابات للمنشورات في هذا الموضوع قد تجلب له الاهتمام الذي يبدو أنه يستحقه!

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

إعجابَين (2)
6

هل يمكنك مشاركة تتبع المكدس الكامل؟ أفترض أن هذا قادم من رمز الـ onebox الخاص بنا، ولكن أود التأكد.

3 إعجابات
7

أفترض أن علينا القيام بذلك من وحدة التحكم - سأضطر إلى أن أطلب من شخص لديه صلاحية الوصول القيام بذلك؛ هل يمكنك إخباري من أين أسحبه حتى أتمكن من تمرير ذلك إلى الشخص الذي لديه صلاحية الوصول؟

شكرا!

8

لا، لا، يتم عرض تتبع المكدس في علامة تبويب في صفحة /logs عند تحديد الخطأ.

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

آه، شكرًا على الإشارة. إليك ما يظهره (تم إخفاء عنوان IP):

رسالة (تم الإبلاغ عن 10 نسخ)

خطأ في المهمة: فشل في فتح اتصال TCP بـ x.x.x.x:443 (الشبكة غير قابلة للوصول - connect(2) لـ "x.x.x.x" المنفذ 443)


تتبع المكدس

/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `initialize'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `open'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1603:in `block in connect'
/usr/lib64/ruby/gems/3.2.0/gems/timeout-0.4.1/lib/timeout.rb:186:in `block in timeout'
/usr/lib64/ruby/gems/3.2.0/gems/timeout-0.4.1/lib/timeout.rb:193:in `timeout'
/usr/lib64/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1601:in `connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:27:in `block in connect'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each_with_index'
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `connect'

لقد لاحظت أن هذا يختلف عن المخرجات في علامة التبويب “تتبع المكدس”، ولكن تلك المخرجات لا تبدو كتتبع مكدس، بل ما هو موجود هنا كنسخة (باستخدام زر النسخ) يبدو كذلك. أخبرني إذا كانت هناك حاجة إلى معلومات أخرى لهذا.

سأرى أيضًا ما إذا كان بإمكاني الحصول على مزيد من المعلومات حول المهام المعلقة البالغ عددها 220 ألفًا بهذه الطريقة أيضًا - لم أكن على علم بنقطة النهاية /logs.

10

هل هناك أسطر إضافية في الجزء السفلي من تتبع المكدس؟

11

كان هذا كل ما التقطه زر النسخ - إليك الإخراج الكامل من علامة التبويب backtrace:

net-http-0.4.1/lib/net/http.rb:1603:in `initialize' 
net-http-0.4.1/lib/net/http.rb:1603:in `open' 
net-http-0.4.1/lib/net/http.rb:1603:in `block in connect' 
timeout-0.4.1/lib/timeout.rb:186:in `block in timeout' 
timeout-0.4.1/lib/timeout.rb:193:in `timeout' 
net-http-0.4.1/lib/net/http.rb:1601:in `connect' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:27:in `block in connect' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `each_with_index' 
/srv/www/vhosts/discourse/lib/final_destination/http.rb:17:in `connect' 
net-http-0.4.1/lib/net/http.rb:1580:in `do_start' 
net-http-0.4.1/lib/net/http.rb:1569:in `start' 
net-http-0.4.1/lib/net/http.rb:1029:in `start' 
/srv/www/vhosts/discourse/lib/final_destination.rb:551:in `safe_session' 
/srv/www/vhosts/discourse/lib/final_destination.rb:486:in `safe_get' 
/srv/www/vhosts/discourse/lib/final_destination.rb:170:in `get' 
/srv/www/vhosts/discourse/lib/retrieve_title.rb:90:in `fetch_title' 
/srv/www/vhosts/discourse/lib/retrieve_title.rb:12:in `crawl' 
/srv/www/vhosts/discourse/lib/inline_oneboxer.rb:76:in `lookup' 
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:310:in `process_inline_onebox' 
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:39:in `block in post_process_oneboxes' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:214:in `block in apply' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:162:in `block in each_onebox_link' 
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:235:in `block in each' 
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:234:in `upto' 
nokogiri-1.16.0/lib/nokogiri/xml/node_set.rb:234:in `each' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:162:in `each_onebox_link' 
/srv/www/vhosts/discourse/lib/oneboxer.rb:213:in `apply' 
/srv/www/vhosts/discourse/lib/cooked_processor_mixin.rb:9:in `post_process_oneboxes' 
/srv/www/vhosts/discourse/lib/cooked_post_processor.rb:42:in `block in post_process' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:53:in `block in synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:34:in `synchronize' 
/srv/www/vhosts/discourse/lib/cooked_post_processor.rb:38:in `post_process' 
/srv/www/vhosts/discourse/app/jobs/regular/process_post.rb:28:in `block in execute' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:53:in `block in synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:49:in `synchronize' 
/srv/www/vhosts/discourse/lib/distributed_mutex.rb:34:in `synchronize' 
/srv/www/vhosts/discourse/app/jobs/regular/process_post.rb:8:in `execute' 
/srv/www/vhosts/discourse/app/jobs/base.rb:297:in `block (2 levels) in perform' 
rails_multisite-5.0.0/lib/rails_multisite/connection_management.rb:82:in `with_connection'
/srv/www/vhosts/discourse/app/jobs/base.rb:284:in `block in perform' 
/srv/www/vhosts/discourse/app/jobs/base.rb:280:in `each' 
/srv/www/vhosts/discourse/app/jobs/base.rb:280:in `perform' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:202:in `execute_job' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:170:in `block (2 levels) in process' 
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:177:in `block in invoke' 
/srv/www/vhosts/discourse/lib/sidekiq/pausable.rb:132:in `call' 
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:179:in `block in invoke' 
sidekiq-6.5.12/lib/sidekiq/middleware/chain.rb:182:in `invoke' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:169:in `block in process' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:113:in `local' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/rails.rb:14:in `block in call' 
activesupport-7.0.8/lib/active_support/execution_wrapper.rb:92:in `wrap' 
activesupport-7.0.8/lib/active_support/reloader.rb:72:in `block in wrap' 
activesupport-7.0.8/lib/active_support/execution_wrapper.rb:92:in `wrap' 
activesupport-7.0.8/lib/active_support/reloader.rb:71:in `wrap' 
sidekiq-6.5.12/lib/sidekiq/rails.rb:13:in `call' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:263:in `stats' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:13:in `call' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_retry.rb:80:in `global' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:124:in `block in dispatch' 
sidekiq-6.5.12/lib/sidekiq/job_logger.rb:39:in `prepare' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:123:in `dispatch' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:168:in `process' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:78:in `process_one' 
sidekiq-6.5.12/lib/sidekiq/processor.rb:68:in `run' 
sidekiq-6.5.12/lib/sidekiq/component.rb:8:in `watchdog' 
sidekiq-6.5.12/lib/sidekiq/component.rb:17:in `block in safe_thread'

آسف لعدم التقاط الإخراج بأكمله. اعتقدت أنه من الغريب أن زر النسخ لم يلتقط المزيد، لكنني افترضت بشكل خاطئ أنه التقط ما هو مطلوب.

12

أوه هذا أفضل بكثير!

[اقتباس=“hendersj, post:11, topic:296783”]
/srv/www/vhosts/discourse/lib/inline_oneboxer.rb:76:in lookup’ `
[/اقتباس]

هذا يعني أن هناك رابطًا مضمنًا واحدًا/العديد من الروابط المضمنة بعنوان URL يحل إلى عنوان IP الخاص بخادمك. إذا تعذر الوصول إلى هذا الخادم، فإننا نسجل الخطأ، ولكن يجب أن تستمر عملية إعداد markdown دون تنفيذ “تجميل الرابط” الذي قد يؤدي إليه onebox المضمن.

شيء آخر، كيف قمت بتثبيت Discourse؟ لا يبدو هذا وكأنه تثبيت اتبع دليل التثبيت الرسمي الخاص بنا.

إعجابَين (2)
13

لم أقم بالتثبيت فعليًا - أعتقد أن فريق البنية التحتية لدينا قام بنشره باستخدام خط أنابيب CI/CD، لكنني لا أعرف التفاصيل.

يبدو أن الرسائل الفاشلة ليست مشكلة - العدد الكبير من المهام الموجودة في قائمة الانتظار في طابور ultra_low يبدو أنه المشكلة الأكبر هنا. لم أعثر على أي شيء في السجلات (وهو أمر منطقي بالنسبة لي، في الواقع، لأن المهمة لم يتم تشغيلها فعليًا بعد).

14

[اقتباس=“hendersj، المشاركة: 13، الموضوع: 296783”]
يبدو أن العدد الكبير من المهام المدرجة في قائمة الانتظار ultra_low هو المشكلة الأكبر هنا. لم أعثر على أي شيء في السجلات (وهذا منطقي بالنسبة لي، في الواقع، لأن المهمة لم يتم تشغيلها بعد).
[/اقتباس]
إذا قمت بفرض تشغيل عدد قليل يدويًا، فماذا يحدث؟

15

لا أرى خيارًا لإجبارهم على التشغيل في واجهة المستخدم على الويب - لدي خيار “إظهار الكل” للوسائط، أو حذف المهام بشكل فردي.

16

حسنًا. ليس لدينا أي عناصر في قائمة الانتظار في المنتدى الذي أساعد في إدارته، لذا أعتذر عن محاولة اقتراح زر غير موجود.

مرجع صفحة إعادة المحاولة، لما اعتقدت أنه كان في صفحة قائمة الانتظار

image
image1077×365 99.5 KB

17

لا تقلق - نعم، تظهر هذه هنا في صفحة Enqueued (على /sidekiq/queues/ultra_low).

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

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

بالحفر قليلاً أعمق في ما أراه في وظائف Jobs::ProcessPost، يبدو أن قيم post_id تتناقص - لقد سحبت معرفات المنشورات من الوظائف الأولى والأخيرة في قائمة الانتظار، وتتوافق التواريخ مع منشور من عام 2012 (قبل الترحيل إلى Discourse - ولكن مع طابع زمني ‘updated_at’ من عام 2022، والذي قد يكون تاريخ الترحيل الخاص بنا - سأضطر إلى التحقق من ذلك) وكان الأحدث من يناير 2023.

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

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

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

هذا يقودني إلى سؤالين:

  1. ما الذي يتسبب في تشغيل مهمة ProcessPost؟
  2. ما الذي قد يتسبب في عدم معالجة قائمة الانتظار ultra_low؟

أنا لست خبيرًا في أي من التقنيات المستخدمة في Discourse (redis، sidekiq، أو rails)، ولكني مرتاح جدًا للتعلم وتجربة الأشياء في بيئتي المعزولة لفهم ما أحتاج إلى أن ينظر إليه شخص ما في بيئة الإنتاج.

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

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

20

يبدو أننا توصلنا إلى حل. التثبيت الذي نستخدمه هو من الحزمة المبنية خصيصًا لـ openSUSE (المثيل الذي كنا نتحدث عنه هو المثيل الخاص بمنتديات openSUSE) - لذا فهو يستخدم بشكل أساسي عملية التثبيت “البناء من المصدر”.

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

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

إعجابَين (2)
21

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.