عمليات البناء تستغرق وقتًا طويلاً جدًا

تستغرق إعادة البناء الخاصة بي حوالي 10 دقائق أو نحو ذلك. أعتقد أنها كانت أقرب إلى 5 دقائق. لذا لا مشكلة كبيرة. ماذا يعني الخطأ إذن؟ أحصل على شيء مشابه لما في المنشور الأصلي أعلاه:

I, [2022-06-20T21:41:47.107238 #1]  INFO -- : cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'
warning "eslint-config-discourse > eslint-plugin-lodash@7.1.0" has unmet peer dependency "lodash@>=4".
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".

سأضيف المزيد إلى هذا أيضًا، أنا أدير نظامًا خفيفًا (1 جيجابايت من ذاكرة الوصول العشوائي) وموقعًا صغيرًا. يحتوي على عاملين من عمال unicorn، وبين كل منهما كان كل منهما يستهلك 30٪ من الذاكرة، مما كان يسبب الكثير من تبديل الذاكرة، لذلك قررت تقليل العدد من 2 إلى 1 (والذي أعتقد أنه يمكن أن يتعامل مع حوالي 10 اتصالات متزامنة لكل منهما). أحدث هذا فرقًا كبيرًا وجعل تحميل الصفحات شبه فوري وقلل التبديل بمقدار 5-10 أضعاف (اعتمادًا على ما كان يتم تحميله).

العيب الذي أراه الآن هو أنني لم أعد أستطيع استخدام ترقيات المتصفح لتحديث discourse. عندما أحاول التحديث عبر المتصفح، أحصل على:

ABORTING, you do not have enough unicorn workers running
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: Not enough workers>

لذا، هذا مجرد شيء يجب ملاحظته، ولست متأكدًا مما إذا كان هذا شيئًا يمكن لفريق Discourse اكتشافه/معالجته - إجراء ترقيات المتصفح باستخدام عامل unicorn واحد.

إعجابَين (2)

يبدو هذا خطأً، خاصة وأن النظام يقلل إلى عامل يونيكورن واحد مؤقتًا بعد ذلك بوقت قصير.

الرقم 2 مبرمج بشكل ثابت، وكذلك الرقم 1 للتخفيض.

تعديل: يبدو أن هذا التغيير أدخل عدم الاتساق

أعتقد أن مشاركتك (وهذا الرد) يجب أن تكون في موضوع جديد، في فئة الأخطاء.

4 إعجابات

كيف يعمل هذا؟

يونيكورن واحد للتعامل مع عملية الترقية، بينما يقوم الباقي بخدمة المكالمات المستمرة؟

وبالتالي، يلزم وجود عاملين يونيكورن كحد أدنى لإجراء ترقيات عبر الإنترنت…؟

هذا خطأ. يمكن لوحيد قرن واحد التعامل مع طلب واحد فقط في كل مرة، لذلك بينما يمكن استخدامه للمجموعات الصغيرة، فإنه ليس شيئًا نوصي به لمعظم المواقع.

إعجاب واحد (1)

@Falco لقد نظرت في بيانات المسؤولين الآخرين. فهمي هو أن كل Unicorn يقوم بإنشاء عملية جديدة لكل اتصال وارد. لذا، بينما هو تقنيًا اتصال واحد في كل مرة، يمكن لكل Unicorn التعامل مع مستخدمين متزامنين متعددين.

بناءً على التجربة المشتركة أدناه، يمكن لحوالي 8 Unicorns التعامل مع ما يقرب من 400 مستخدم متزامن.

بناءً على ذلك، يبدو أن كل Unicorn يمكنه التعامل مع حوالي 50 مستخدمًا متزامنًا. الآن، أعلم أن ذاكرة الوصول العشوائي (RAM) وموارد النظام تحدث فرقًا في عدد العمليات التي يمكن إنشاؤها وما إلى ذلك، ومن هنا جاء افتراضي بأن عامل Unicorn واحد يمكنه التعامل مع 10 مستخدمين متزامنين على نظام بذاكرة وصول عشوائي منخفضة (1 جيجابايت) في الحد الأدنى.

هل افتراضاتي + استنتاجاتي خاطئة تمامًا؟ إذا كان الأمر كذلك، فما هو نطاق المستخدمين المتزامنين الذي يمكن لكل Unicorn التعامل معه اعتمادًا على موارد النظام (بافتراض 1 جيجابايت في الحد الأدنى وأي شيء تشعر أنه مناسب في الحد الأعلى)؟

إعجاب واحد (1)

هناك فرق بين جلسات المستخدم المتزامنة والاتصالات المتزامنة. الجلسة هي مستخدم متصل بالإنترنت، وكل منهم يقوم بطلب (اتصال) كلما تفاعل.\n\n[quote="RBoy, post:27, topic:217001, username:RBoy"]\nفهمي هو أن كل Unicorn يقوم بعمل نسخة جديدة من العملية لكل اتصال وارد\n[/quote]\nلا يفعل ذلك. يقوم Unicorn بعمل نسخة إلى عدد محدد من عمليات العامل عند بدء التشغيل.

إعجاب واحد (1)

وأعتقد أننا رأينا أن كل عملية عامل تدير 10 خيوط.