مشكلة بطء شديد في Sidekiq مع طابور كبير بسبب أعداد هائلة من إشعارات المستخدم غير المقروءة

الدعم تثبيت
1

لذا أواجه مشكلة مع Sidekiq.

يعمل بسرعة مذهلة في معالجة الوظائف عند مراقبته عبر واجهة Sidekiq الويب. لكن في بعض الأحيان يبدو أنه يُغمر بالطلبات ويبدأ في العمل ببطء شديد. يعمل بنسبة 1-5% تقريبًا من سرعته العادية ولا يتعافى إلا بعد تفريغ Redis، على الرغم من أن استخدام موارد الخادم طبيعي/منخفض.

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

يصف هذا GIF ما يبدو عليه الأمر بالنسبة لي.

simpsons_EDIFIL20161024_0001
simpsons_EDIFIL20161024_0001425×305 965 KB

هناك وفرة من موارد الخادم المتاحة، واستخدام المعالج منخفض جدًا حاليًا - أقل من 10%. كما تتوفر ذاكرة عشوائية (RAM) وقرص SSD بكثرة. فيما يتعلق بالخادم، فهو يحتوي على 16 نواة مع 32 خيطًا. لقد جربت تشغيل ما بين 8-14 عملية unicorn_sidekiq. كما جربت 20، لكن ذلك أدى إلى ظهور العديد من أخطاء 5xx.

تمكنت من تسريع الوظائف البطيئة المعروضة في علامة التبويب ‘Busy’ في واجهة Sidekiq الويب باستخدام
Could sidekiq queue be reason for 500 errors? - #30 by bartv (
بإضافة ‘vm.overcommit_memory = 1’ إلى ملف /etc/sysctl.conf وإعادة تشغيل النظام) وكذلك تقليل عدد unicorn_sidekiqs إلى 8 (من 12).

ما زال يعمل ببطء. لقد لاحظت هذا في سجل Redis أمس (كان التحذير الوحيد الآخر يتعلق بعدم ضبط overcommit_memory على 1، وهو ما قمت بتعديله أعلاه):

# WARNING: /proc/sys/net/core/somaxconn is set to the lower value of 128

^ هل قام أي شخص بحل هذا التحذير أعلاه؟

على أي حال، إذا كان لدى أي شخص أي أفكار حول ما قد يكون السبب و/أو الحل - فيرجى إخباري. سأقدر ذلك.

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

إليك لقطة شاشة لما أراه على لوحة تحكم Sidekiq:

Screen Shot 2020-02-05 at 6.52.24 PM
Screen Shot 2020-02-05 at 6.52.24 PM2386×1688 1.02 MB

وبعض لقطات الشاشة للوظائف تحت علامة التبويب Busy:

Screen Shot 2020-02-05 at 6.42.03 PM
Screen Shot 2020-02-05 at 6.42.03 PM1214×2178 450 KB

أيضًا، هل يعرف أحد ما إذا كان آمنًا استخدام هذا الخيار؟ حذف طابور الأولوية المنخفضة من واجهة Sidekiq الويب؟

Screen Shot 2020-02-05 at 6.47.18 PM
Screen Shot 2020-02-05 at 6.47.18 PM2396×492 89.9 KB

2

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

3

هل تتوفر لديك مقاييس حول المدة التي تستغرقها مهامك؟ يبدو أن هناك ازدحامًا كبيرًا في مهام PostAlert، بينما تُستكمل المهام الأخرى بسرعة.

4

بناءً على ما لاحظته في واجهة Sidekiq الويب. نعم، أنت محق، يبدو أن الوظائف الأخرى تُكتمل بسرعة باستثناء:

Jobs::PostAlert - من 0 إلى 3 دقائق، مع أن الغالبية تقع في نطاق من 0 إلى دقيقة واحدة.
Jobs::ProcessPost - من 0 إلى 21 ثانية.

5

هل خادم SMTP الخاص بك بطيء؟

6

أنا أستخدم Amazon SES للإرسال، وقمت أيضًا بتكوين مستلم البريد لاستقبال VERP.

حد الإرسال المعروض على SES هو 25 بريدًا إلكترونيًا في الثانية. هل هذا بطيء جدًا؟ يمكنني على الأرجح طلب زيادته.

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

7

كم عدد المستخدمين الذين ترسل لهم البريد الإلكتروني؟ وكيف تبدو أحجام البريد المرسلة؟

8

غير متأكد من عدد المستخدمين الذين يتم إرسال رسائل البريد الإلكتروني إليهم. آخر إحصائية للمستخدمين النشطين خلال 30 يومًا من لوحة تحكم المسؤول هي 60.8 ألف، ربما تكون هذه مؤشرًا؟ إليك إحصائيات الإرسال من SES (حد 100 ألف+ خلال 24 ساعة):

Screen Shot 2020-02-06 at 1.47.59 PM
Screen Shot 2020-02-06 at 1.47.59 PM1382×818 83.4 KB

9

تحديث: تم زيادة حد إرسال SES في الثانية من 25 إلى 50. وبالتالي، يمكن الآن إرسال 180 ألف بريد إلكتروني في الساعة (على الرغم من أن الحد المسموح به يوميًا هو قليلًا أكثر من 100 ألف). ومع ذلك، لا يبدو أن سرعة معالجة وظائف Sidekiq قد تحسنت.

10

واجهنا مشكلة قبل بضع سنوات حيث كان لدى المستخدمين 10 آلاف إشعار غير مقروء، مما كان يؤدي إلى إبطاء استعلامات الإشعارات، وبالتالي إبطاء مهمة PostAlert.

أضفنا حماية لمنع تكرار ذلك إلى حد كبير، لكن قد تظهر خصائص أداء مختلفة في إعدادك.

هل لديك مستخدمون تم تعيينهم لمراقبة فئات ولا يهتمون بعدد الإشعارات؟

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

11

لذا قمت بتفريغ قائمة الأولوية المنخفضة مرة أخرى وتركتها لبضعة أيام (لم تحدث أي تغييرات منذ آخر تحديث لي) - لم تتسارع الأمور على الفور وتراكم الوظائف المعلقة بسرعة، لكن يبدو أنها أصلحت نفسها مع مرور الوقت. الآن معالجة الوظائف تسير بسرعة هائلة. :slight_smile: باستخدام فترة استطلاع مدتها 20 ثانية، أرى نطاقًا يتراوح بين 55 و140 وظيفة في الثانية خلال الدقائق القليلة الماضية. يبدو الأداء اليومي صحيًا أيضًا دون تراكم في الطابور.

شكرًا جزيلاً على المساعدة @Falco @supermathie @Stephen، لقد قدّرت ذلك حقًا!

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

12

ربما تسرّعت في الكلام. تعمل وظائف Sidekiq حاليًا بمعدل يقارب 1 إلى 3 في الثانية مع طابور يبلغ 8.81 مليون.

:philosoraptor:

Screen Shot 2020-02-10 at 6.43.33 PM
Screen Shot 2020-02-10 at 6.43.33 PM1208×3142 679 KB

13

متى قمتِ بالتحديث آخر مرة؟ لقد أضفت بعض التحسينات في الأداء إلى مهمة PostAlert قبل بضعة أيام:

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

14

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

15

تحديث: للأسف، لم تحدث أي تحسينات فورية في السرعة منذ التحديث. سنرى ما إذا كانت ستتحسن مع مرور الوقت.

16

تحديث: لا يزال النظام يعمل ببطء، وتتراكم الطابور. تظهر عمليات postmaster بكثرة عبر أمر ‘top’. استهلاك المعالج الإجمالي يبلغ حوالي 85% (32 نواة)، ومعظم هذا الاستهلاك ناتج عن postmaster. وهذا مثير للاهتمام، حيث كان استهلاك المعالج في وقت سابق من اليوم يتراوح بين 20-35% (كان sidekiq يتحرك ببطء أيضًا في ذلك الوقت). ذو صلة: Primary Postgres database process (postmaster) eating all CPU - #5 by pfaffman

17

هل تعتقد أن تحذيرات Redis هذه قد تكون مرتبطة بالمشكلة؟ تظهر هذه التحذيرات أثناء إعادة بناء التطبيق:

# تحذير: لا يمكن تطبيق إعداد TCP backlog البالغ 511 لأن /proc/sys/net/core/somaxconn مضبوط على القيمة الأقل وهي 128.

# تحذير: لديك دعم Transparent Huge Pages (THP) مفعّل في نواة النظام. هذا سيسبب مشاكل في زمن الاستجابة واستخدام الذاكرة مع Redis. لحل هذه المشكلة، قم بتشغيل الأمر 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' بصلاحيات root، وأضفه إلى ملف /etc/rc.local للحفاظ على الإعداد بعد إعادة التشغيل. يجب إعادة تشغيل Redis بعد تعطيل THP.

هل نجح أحدكم في إصلاح هذه الأخطاء في تثبيت Docker؟

لقد أضفت بالفعل vm.overcommit_memory = 1 إلى ملف /etc/sysctl.conf لإصلاح تحذير overcommit memory.

18

لذا قمت بإصلاح تحذير Transparent Huge Pages (THP) بتشغيل الأمر echo never > /sys/kernel/mm/transparent_hugepage/enabled بصلاحيات الجذر (root). لم أقم بإضافته إلى rc.local للاستمرارية بعد، بل فقط للاختبار. قمت بإعادة بناء Discourse، والأداء متقارب تقريبًا - ربما تحسن طفيف.

لكنني لست متأكدًا تمامًا من كيفية إصلاح هذا التحذير:
# WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

لاحظت أن بعض الأشخاص يقولون إن Docker ستظل تستخدم القيمة 128 حتى لو تم تعيين قيمة النظام أعلى، مثلما هو موضح في دليل مثل هذا: Performance tips for Redis Cache Server – Tech and Me

19

أفكر في أن فكرة تخصيص بعض عمال UNICORN_SIDEKIQS لطابور الأولوية المنخفضة قد تكون جيدة.

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

هل يعرف أحد ما إذا كان من الممكن تخصيص عمال UNICORN_SIDEKIQS في ملف app.yml (أو بطريقة أخرى) لمهام أولوية محددة؟

20

إضافة المزيد من Sidekiqs بينما قاعدة البيانات هي عنق الزجاجة سيجعل الأمر أسوأ فقط.

كما قلت أعلاه، تحتاج إلى تصحيح مشكلة الأداء السيئ في PostgreSQL.