هل يمكن أن يشير هذا إلى أن UNICORN_WORKERS تم تعيينه على قيمة عالية جدًا/منخفضة جدًا؟
يحتوي الخادم على 64 جيجابايت من ذاكرة الوصول العشوائي (RAM) (عادة ما تظهر حوالي 40 جيجابايت مجانية) و 6 أنوية، وهناك 4 مثيلات من Discourse على الخادم، تم تعيين كل منها على UNICORN_WORKERS: 8
هل لديك أي أفكار أو نصائح حول سبب ذلك أو ما يجب تجربته؟ (أحد المنتديات في وضع القراءة فقط ولا يحصل على الكثير من الزيارات، هل يجب تعيينه ليكون لديه عدد أقل من العمال؟)
شكراً لجميع الردود - لست متأكداً من أين قرأتها الآن ولكنني كنت أعتقد دائماً أنه يجب علينا تعيين عاملين لكل نواة. لقد قللت الآن عدد العمال لكل منتدى، مع تخصيص المزيد للمنتديات الأكثر ازدحاماً وأقل للمنتديات الأقل ازدحاماً. سأراقب الأمور خلال الأسبوع المقبل وسأبلغ عن ذلك إذا لم يساعد ذلك.
نعم… لقد قمت بالتعديل بحيث لا يتجاوز العدد الإجمالي للعاملين ضعف عدد الأنوية، على الرغم من أنني ما زلت أتساءل - ما هي النصيحة الصحيحة/المعيارية، ما قلته أنت أم ما كان في منشور نيت، حيث يقتبس جيف قائلاً عامل واحد لكل نواة؟
من تجاربي الخاصة، يؤدي عامل واحد لكل نواة إلى انتهاء المهلة (ولكنه يقلل من حمل الخادم) والمزيد من العمال يؤدي إلى أداء أفضل ولكن حمل أعلى (والذي لا يزال ضمن نطاق مقبول على خادمي).
إلق نظرة على discourse-setup، الذي يتعامل مع التوسع للتثبيتات الجديدة اليوم:
# UNICORN_WORKERS: 2 * GB for 2GB or less, or 2 * CPU, max 8
if [ "$avail_gb" -le "2" ]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
هذه العبارة الثانية، التي تستخدم ضعف عدد الأنوية المتاحة، هي الافتراضية في الأنظمة التي تحتوي على أكثر من 2 جيجابايت من ذاكرة الوصول العشوائي. يبدو أن مشكلتك تتعلق أكثر بالصراع بين مثيلاتك (موارد المضيف)، بدلاً من مشكلة discourse.
أرى نفس الشيء بعد آخر ترقية لي، والتي كانت بعد يوم واحد من المنشور الأصلي، لذلك لا أعتقد أن هذا له علاقة بعدد عمال يونيكورن. عملية unicorn.conf.r* تثير الشبهات، لأن المنشور الأصلي لهذا الموضوع هو النتيجة الوحيدة لهذا المصطلح على شبكة الإنترنت بأكملها. أعتقد أن unicorn.conf.rb سيكون أكثر طبيعية.
لقد قمت للتو بالترقية إلى أحدث إصدار من Discourse ولم أعد أرى unicorn.conf.r* (الآن أي شيء حول علامة 80% من وحدة المعالجة المركزية هو مجرد ruby، على الرغم من أنه يبدو أقل تكرارًا). الأحمال متساوية تقريبًا (على الرغم من أنها أقل مما كانت عليه بعد إجراء تعديلات العامل).
هل قمت بالترقية إلى أحدث إصدار؟ ما نوع الأجهزة التي تستخدمها ومدى انشغال منتداك؟
نعم، أنا على الإصدار 3.4.0.beta4-dev. هذا هو ما بدأ استخدام وحدة المعالجة المركزية المرتفع. لم يتغير شيء آخر.
8 جيجابايت من ذاكرة الوصول العشوائي، 2 وحدة معالجة مركزية افتراضية، 160 جيجابايت SSD مع مساحة كافية.
لقد نشرت استخدام وحدة المعالجة المركزية أعلاه لموقع الإنتاج الخاص بي، والذي يحتوي على حوالي 30 مستخدمًا متصلين في وقت واحد. ولكن لدي موقع اختبار به نفس المشكلة ولا توجد حركة مرور ولا إضافات هناك. استخدام وحدة المعالجة المركزية قبل وبعد التحديث (الارتفاعات هي النسخ الاحتياطي اليومي):
لست متأكدًا مما إذا كانت مواقفنا مرتبطة يا مارك. أعتقد في حالتي أن ما قاله ستيفن لعب دورًا كبيرًا:
لقد نقلت مؤخرًا مثيلين آخرين إلى نفس الخادم ونسيت بالفعل أن عمال يونيكورن تم ضبطهم على 8 لأننا كنا سابقًا على خادم به نوى أكثر (لكنه كان به مشاكله الخاصة، ولهذا عدنا إلى Xeon الذي كان به نوى أقل ولكنه كان يعمل بشكل أفضل بشكل عام).
لذا، ما وجدته هو أن تقليل عمال يونيكورن على هذا الخادم قلل الحمل، ولكنه بدأ يعطينا مهلات زمنية، وزيادتها قضت على المهلات الزمنية ولكنها أدت إلى حمل أعلى - على الرغم من أنه لا يزال ضمن نطاق مقبول. أعتقد أنه يمكنني زيادة العمال ويمكننا التعامل مع الحمل المتزايد، ولكن ما لدينا الآن جيد في الوقت الحالي.
مع ذلك، لقد نقلت المثيلات إلى نفس الخادم وكان يعمل ضمن ما كنت أتوقعه (لذا زاد الحمل ولكن ليس بشكل كبير) وشعرت بالفعل أن التحديث أدى إلى أحمال أعلى… ومع ذلك لا يمكنني التأكد من ذلك، وعلينا أن نأخذ في الاعتبار أنه من وقت لآخر مع حصول Discourse على المزيد من الميزات قد يتطلب أجهزة أقوى أو يؤدي إلى الشعور أحيانًا بأنه “أبطأ” (كان لدي بعض مثيلات Discourse على إصدارات قديمة وشعرت بأنها أسرع بشكل ملحوظ - على الرغم من أنها بالطبع لم تكن بها جميع ميزات الإصدارات الأحدث).
مع ذلك أيضًا، أعتقد أن الأحمال قد انخفضت قليلاً منذ آخر تحديث لـ Discourse (مع PG 15).
لست متأكدًا مما أقترحه لك يا مارك - ربما تلعب بإعدادات العمال وبعض الإعدادات الأخرى أيضًا؟ مثل db_shared_buffers و db_work_mem؟ ربما تبدأ موضوعًا مخصصًا على غرار “استخدام وحدة المعالجة المركزية مرتفع بعد التحديث - هل يحتاج مثيلي إلى تعديلات في الأداء؟” أو شيء من هذا القبيل
لقد قمت بالترقية الليلة وشاهدت على الفور اختلافًا في استخدام وحدة المعالجة المركزية على موقعي. إليك رسم بياني لما قبل الترقية وأثناءها وبعدها. يمثل هذا مدة ساعة واحدة.
إذًا، يبدو أن مشكلتي لم تكن في عمال unicorn بعد كل شيء - بعد تحديث @sam الذي تلى الموضوع الخاص بـ @LotusJeff، عادت أحمال الخادم إلى ما كانت عليه (أقل من نصف ما ارتفعت إليه)…
ربما لم أكن لألاحظ لو لم أكن أراقب الخادم بعد أن قمت مؤخرًا بنقل المنتديين الآخرين عليه - أتساءل كم عدد الأشخاص الذين تأثروا دون أن يدركوا ذلك؟
هل لدى فريق Discourse إجراءات معمول بها لتنبيههم بالمشكلات مثل هذه؟ ربما برنامج تطوعي يمكن للمسؤولين إعداده لمواضيع محددة، على سبيل المثال، “إرسال أحمال الخادم إلى Discourse في غضون XX ساعات/أيام/أسابيع قبل/بعد الترقية” أو الأفضل من ذلك تتبع هذه محليًا ثم تنبيه المسؤولين عند ملاحظة زيادة أحمال الخادم بعد الترقيات - والتي يمكننا بعد ذلك نشرها هنا إذا لزم الأمر.
ربما لم أكن لألاحظ التأثير، لكنني أراقب الخادم عن كثب لأننا انتقلنا إلى Discourse قبل حوالي أسبوعين. أنا منغمس في التحقق من صحة ما بعد الترحيل (تشغيل النسخ الاحتياطي، وما إلى ذلك). بعد بضعة أشهر، لن ألاحظ التأثير أبدًا.
آمل أن يكون لدى Discourse اختبار تحميل يومي. في حياتي السابقة، كان لدي خادم يعاد بناؤه يوميًا مع الرموز الملتزم بها. كان لديه مستخدمون محاكون يستخدمون الخادم طوال اليوم. قسنا مقاييس الأداء الرئيسية من منظور المستخدم ومن منظور الخادم. سمح لنا ذلك بالتقاط تسرب الذاكرة، والرموز غير الفعالة، والتغييرات غير المتوقعة في تجربة المستخدم بشكل استباقي.
لا يزال يتعين علي تقديم الشكر لسام والفريق. بالانتقال من عالم phpBB، حيث سيستغرق حل شيء كهذا وإصلاحه عقودًا، وجدت الاستجابة السريعة رائعة. (حتى لو كان ذلك يعني البقاء مستيقظًا حتى الساعة 2 صباحًا بتوقيت CT مقارنة بتوقيت سيدني.)
