هل يمكن لأحد أن يقدم توضيحًا حول تجميع قواعد بيانات عمال Sidekiq؟
حاليًا، قمنا بتعيين DISCOURSE_DB_POOL إلى 15، مع عاملين Sidekiq، لكل منهما تزامنية تبلغ 10. بعد قراءة وثائق Sidekiq، يبدو أن خيوط Sidekiq تشترك في مجمع قاعدة البيانات، ومن ثم أتوقع حدًا أقصى قدره 15 * 2 = 30 اتصالًا بقاعدة البيانات من عمال Sidekiq. ومع ذلك، على الرغم من هذا الفهم، نلاحظ ارتفاعات في اتصالات قاعدة البيانات تتجاوز الحد الأقصى المتوقع البالغ 30.
أخشى أنني لا أعرف تفاصيل كيفية عمل كل هذا على الفور.
قد يكون من المفيد التحقق مما إذا كنت قد قمت بتخصيص متغير البيئة UNICORN_SIDEKIQS. يشير هذا إلى عدد عمليات sidekiq التي يتم تشغيلها (كل منها سيكون له العديد من الخيوط).
ما الذي يظهره الرسم البياني الخاص بك بالضبط؟ هل هو “الاتصالات المتزامنة”؟ أم أنه “عدد الاتصالات التي تم إنشاؤها”؟ إذا كان الأخير، فربما يتم إنشاء بعض الاتصالات وتدميرها بسرعة كبيرة.
وسؤال أخير: ما المشكلة التي تحاول حلها هنا؟ هل هناك أي مشكلة ناتجة عن عدد الاتصالات؟
شكراً على عودتك.\n\nفيما يلي التكوينات ذات الصلة التي لدينا:\n\n* DISCOURSE_DB_POOL: “15”\n* DISCOURSE_SIDEKIQ_WORKERS: “10”\n* UNICORN_SIDEKIQS: “2”\n\nهذا يعني أن لدينا عمليتي Sidekiq، كل منهما بها 10 خيوط.\n\nيوضح الرسم البياني العدد الحالي لاتصالات العميل.\n\nنحن نحاول تكوين حجم تجمع الاتصال (RDS proxy أمام PostgreSQL) بشكل صحيح. للقيام بذلك، نحتاج إلى فهم أفضل لتجميع الاتصالات من جانب التطبيق. لماذا لا يحترم التطبيق تكوين DISCOURSE_DB_POOL كما هو متوقع؟\nإذا كان DISCOURSE_DB_POOL يعمل كما هو متوقع، فلماذا نرى مثل هذه الزيادات الكبيرة في اتصالات قاعدة البيانات؟ يبدو أن هذه الزيادات تتماشى مع تشغيل الوظيفة المجدولة PeriodicalUpdates.\n\nيرجى إعلامي إذا كان لديك المزيد من الأسئلة. أقدر المساعدة في كشف هذا اللغز.
