أرى هذه الأخطاء بشكل متزايد في السجلات. هل يجب أن أرفع حد Sidekiq RSS قليلاً في /var/discourse/containers/app.yml:
env:
SIDEKIQ_MEMORY_KILLER_MAX_RSS: 700
أم أن هذا طبيعي ويجب تجاهله؟
إعجاب واحد (1)
إليك ما نجح معي.
بعد مراقبة استخدام الذاكرة وتعديل إعداداتي، تمكنت من إيقاف الرسائل المتكررة “Sidekiq يستهلك الكثير من الذاكرة…” /log.
لقد أجريت هذا التغيير في /var/discourse/containers/app.yml الخاص بي:
UNICORN_WORKERS: 4
UNICORN_SIDEKIQ_MAX_RSS: 700
في الأصل، كنت قد ضبطت UNICORN_WORKERS على 8، وهو ما كان عدوانيًا للغاية وترك متسعًا ضئيلًا لـ Sidekiq و PostgreSQL و Redis ونظام التشغيل.
أدى خفض عدد العمال إلى 4 إلى تحرير قدر كبير من الذاكرة.
ثم قمت بزيادة حد Sidekiq RSS من الافتراضي (حوالي 500 ميجابايت) إلى 700 ميجابايت، مما يمنح Sidekiq مزيدًا من المساحة قبل إعادة تشغيله تلقائيًا.
حتى الآن، استقر Sidekiq، ويقع استخدام الذاكرة الآن في منطقة أكثر أمانًا بكثير، مع انتقال ما يزيد قليلاً عن 1 جيجابايت من الذاكرة المستخدمة إلى الذاكرة المخزنة والمتاحة.
سأترك هذا هنا إذا ثبت أنه مفيد أو كتلميح لما يجب النظر إليه لأي شخص آخر لديه مشاكل مماثلة. سيكون من المثير للاهتمام معرفة ما إذا كان هذا سيستمر ويكون أكثر استقرارًا بعد أسبوع من التشغيل، وإذا كان الأمر كذلك، فسأضع علامة “تم الحل”.
إعجابَين (2)
كان لدي أيضًا هذا الإشعار مؤخرًا وقمت بتعديله كما فعلت (إلى 1 جيجابايت) ولم يظهر الخطأ مرة أخرى 
إعجاب واحد (1)
تم التأكيد على أن التغييرات نجحت. آخر إعادة تشغيل لـ Sidekiq كانت 11 Oct 12:48 pm.
إحصائيات الذاكرة اليوم:
كانت هذه المنتديات تحتوي على مواضيع مفيدة (مرتبطة أعلاه) كانت مفيدة. نأمل أن يساعد هذا شخصًا آخر أيضًا.
ما وجدته هو أن منتداي لا يحصل على القدر الكافي من حركة المرور ليتطلب 8 عمال. حتى 2 كان سيعمل بشكل جيد.
ومع ذلك، يبدو أن الذاكرة بها مساحة أقل قليلاً، لكنني أخطط لمواصلة تشغيل الجهاز الافتراضي بنفس الحجم. نظرًا لأن التبديل (swap) سريع جدًا على NVMe في RAID 10، سأضيف في النهاية في المستقبل zswap وأقوم بتحديث هذا الموضوع في السنوات القادمة إذا/عندما تتطلب حركة المرور ذلك.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.