نقوم بتشغيل العديد من مواقع Discourse باستخدام multisite تحت تطبيق واحد. مؤخرًا، أجرينا دفعة من عمليات استيراد المستخدمين الكبيرة (مئات الآلاف من المستخدمين عبر 6 مواقع). بعد عمليات الاستيراد، يقوم Sidekiq بمعالجة المهام الخلفية ببطء شديد. تعرض لوحة تحكم Sidekiq قائمة انتظار ضخمة، وتتم إزالة المهام بمعدل أبطأ بكثير من المتوقع.
تفاصيل البيئة:
- تمت ترقية الجهاز الافتراضي إلى 16 وحدة معالجة مركزية / 16 جيجابايت من ذاكرة الوصول العشوائي.
- ومع ذلك، في واجهة Sidekiq، نرى 5 خيوط فقط ويبدو أنه يتم استخدام جزء صغير فقط من الموارد.
- قائمة الانتظار الرئيسية للاستيراد (“nursingjobs” كوالد multisite) تعالج المهام لجميع المواقع الفرعية، ولكن إنتاجية المهام منخفضة جدًا.
- مقاييس الخادم: وحدة المعالجة المركزية أحيانًا عند 80-90٪، والذاكرة حوالي 6.7 / 7.2 جيجابايت.
نحن نتطلع إلى:
- تسريع معالجة مهام Sidekiq / الخلفية لمسح قوائم الانتظار الكبيرة بعد الاستيراد.
- ضمان استخدام Discourse لجميع الموارد المتاحة (وحدة المعالجة المركزية / ذاكرة الوصول العشوائي).
- فهم ما إذا كانت هناك حدود للخيوط / العمليات تحتاج إلى تعديل.
أسئلة:
- ما هي أفضل طريقة لتكوين Sidekiq / Discourse لإنتاجية عالية بعد الاستيراد؟
- ما هي الإعدادات الموصى بها لـ UNICORN_SIDEKIQS و DISCOURSE_SIDEKIQ_WORKERS على الأنظمة الكبيرة متعددة النوى؟
- هل هناك إعدادات Postgres أو إعدادات app.yml أخرى يجب علينا تعديلها لتجنب أخطاء مجمع قاعدة البيانات عند زيادة تزامن Sidekiq؟
- أي أفضل الممارسات لمسح قوائم انتظار Sidekiq الضخمة بسرعة وأمان بعد عمليات الاستيراد؟
إحصائيات / لقطات شاشة Sidekiq متاحة إذا كانت مفيدة!
