إذًا كل الادعاءات بأن UNICORN WORKER يجب أن يكون 2*vCPU خاطئة؟
خادمي هو Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32GB Ram
كم عدد UNICORN WORKER الذي أحتاج إلى إعداده؟
8؟ أم 48؟
موقعي لديه أكثر من 7 آلاف مستخدم وحوالي 1000 مستخدم نشط يوميًا. يرسل المستخدمون 3 آلاف - 7 آلاف منشور يوميًا. مجتمعنا لديه 120 ألف - 200 ألف مشاهدة صفحة يوميًا بما في ذلك الزواحف والمستخدمين المجهولين.
هذا يعتمد على العديد من العوامل. مثل حجم قاعدة البيانات لديك مقارنةً بذاكرة الوصول العشوائي (RAM)، ونسبة حركة المرور المسجلة الدخول إلى حركة المرور المجهولة، وما إذا كان لديك إضافات تجعل قائمة انتظار Sidekiq أكثر انشغالاً، وما إذا كنت تشغل YJIT، وما إلى ذلك.
البسيط هو النظر إلى بيانات MiniProfiler خلال ساعة الذروة لديك وتصفح المنتدى لمعرفة ما إذا كان الأداء أسوأ وتحديد عنق الزجاجة.
نظرًا لأن وحدة المعالجة المركزية هذه قديمة، سأبدأ بعدد أكبر من عمال Unicorn المعتاد، حيث سيستغرق كل طلب وقتًا أطول من المعتاد. ولكن إذا كنت تشغل PostgreSQL و Redis على نفس الخادم، فلا يمكنك حرمانها من خلال تشغيل الكثير من العمال.
جرب تشغيل 16 عاملاً للبدء، وقم بتقييم أداء الموقع.
هل هناك وصف بسيط وسهل الفهم لما تفعله وحدات عمل Unicorn؟ الانطباع الذي لدي هو أن كل طلب صفحة مستخدم يجب أن يذهب إلى عامل Unicorn للتعامل معه. إذا لم يكن لديك ما يكفي، فعلى المستخدم الانتظار. إذا كان لديك الكثير… حسنًا، ربما يكلفك ذلك القليل من ذاكرة الوصول العشوائي (RAM)؟
إنها خوادم الويب للتطبيقات.
إعجاب واحد (1)
يبدو أن وحدة المعالجة المركزية التي يبلغ عمرها 10 سنوات تظهر عليها علامات التقدم في العمر. زيادة عدد عمال Unicorn ستسمح لك بخدمة المزيد من المستخدمين في وقت واحد ولكنها لن تجعل الطلب الفردي أسرع.
هل يمكنك محاولة تمكين YJIT؟
3 إعجابات
مع أجهزتك، أتوقع الحصول على متوسط وقت تسجيل دخول/آخر وقت مسجل حوالي 150 مللي ثانية للتطبيق، و 80 مللي ثانية لقاعدة البيانات.
أود أن أبدأ بـ 12 عاملًا وأرى كيف يتصرف مع هذا العدد. أفضل شيء يمكنك القيام به هو تتبع المقاييس؛ إذا كنت تريد معرفة ما إذا كان يجب عليك إضافة المزيد من العمال، فتحقق مما إذا كانت الطلبات تنتظر في قائمة الانتظار لتطبيق العمال.
هل تتتبع المقاييس التي يصدرها Discourse نفسه عبر مُصدِّر Prometheus؟ ستمنحك هذه نظرة جيدة على كيفية أداء المثيل بشكل عام.
ما هي أرقام الأداء للمستخدمين المجهولين والمستخدمين العاديين (غير الإداريين)؟
5 إعجابات
هناك العديد من المواضيع الضخمة في Discourse الخاص بنا، وأكبرها هو بالفعل في القسم الثاني عشر.
عرض الردود
إعجاب واحد (1)
(/ يتوقف عن الضحك، ويسجل الدخول إلى مزود الاستضافة … )
واو، أليس هذا هو الافتراضي الآن؟
تعديل: آه بالطبع ربما تكون قد بنيت باستخدام تطبيق قديم. yml ولم تقم بالتحديث منذ ذلك الحين
إعجاب واحد (1)
إنه موجود في الاستضافة الخاصة بنا، ولكنه صعب بعض الشيء لجعله افتراضيًا حيث قد يعمل الأشخاص في سيناريوهات مقيدة بالذاكرة العشوائية…
ومع ذلك، فإن بناء JavaScript الخاص بنا يستهلك ذاكرة عشوائية أكثر بكثير من Discourse نفسه، لدرجة أنه يمكنك القول أن أي شخص يمكنه بناء أصول JavaScript لديه الكثير من الذاكرة العشوائية لتبادلها 
إعجاب واحد (1)
في هذه الصور، كم عدد العمال الذين قمت بإعدادهم؟
أقول إنه يجب عليك
- زيادة عدد العمال قليلاً، حيث تحصل على بعض الانتظار في الطابور
- تمكين YJIT، حيث أن وقت الويب الخاص بك بطيء جدًا
هناك 8 عمال فقط الآن، وتم تمكين YJIT بالفعل.\nكم عدد العمال الذين يجب أن أزيدهم؟
بالمناسبة، إليك ما كان يراقبه فالكو لتقديم هذه التوصية:
أود زيادة العدد من 8 إلى 12. هذا يمنحك بعض المساحة الإضافية ويجب أن يزيل هذه الطوابير.
هذه الزيادة الكبيرة، بالمناسبة، تشير إلى طلبات أخرى تنتظر… شيئًا ما، ربما قفل مشترك. ربما منشور موضوع ضخم.
إذا كان بإمكانك الحصول على مقاييس استخدام postgres أيضًا، فسيكون ذلك مفيدًا.
المواضيع الضخمة هي نقطة ضعف، انظر Improving Instance Performance (Megatopics, Database Size and Extreme Load)
فكر في تقسيمها أو استخدام الدردشة بدلاً من ذلك (أرى أن أكبر موضوع لديك مع 8.9 ألف رد هو غرفة دردشة بشكل صريح).
ثقافة المناقشة في مجتمعنا هي megatopics، والتي تشكلت حتى قبل أن نبدأ في استخدام Discourse، ويفتقر الدردشة إلى ميزات التلميحات المموهة والتفاصيل المخفية
إعجاب واحد (1)
كيف أفعل ذلك
نحن نستخدم https://github.com/prometheus-community/postgres_exporter، على الرغم من أنني لست متأكدًا مما إذا كانت هناك أي أدلة حول كيفية إعداده.
ولكن، بالنظر إلى أن لديك بالفعل Prometheus معدًا، يبدو أنك تعرف ما تفعله.
الآن ذاكرة الوصول العشوائي للخادم هي 16/32 جيجابايت، UNICORN_WORKERS: 12، db_shared_buffers: “4096MB”
نظرًا لوجود ذاكرة وصول عشوائي لا تزال متاحة وعدد قليل من طلبات الويب في قائمة الانتظار، قمت بزيادة UNICORN_WORKERS إلى 24. بعد ظهر اليوم، تعطل الخادم فجأة وبعد إعادة تشغيله، تدفق المستخدمون على الفور. أدى هذا إلى عدد قليل جدًا من طلبات الويب النشطة وعدد كبير من الطلبات في قائمة الانتظار. قبل أيام قليلة، لاحظنا أن 24 UNICORN_WORKERS يمكنها التعامل مع أكثر من 150 طلب ويب نشط، ولكن 30 طلب ويب نشط فقط بعد ظهر اليوم. هذا بسبب أننا قمنا للتو بتغيير النطاق، وهناك العديد من المشاركات التي يتم إعادة خبزها بواسطة sidekiq. تسبب هذا في ضغط كبير على الخادم. ماذا يجب أن نفعل؟
