يبدو أن 2+2 لم تعد كافية… أنا أدير نسخة Discourse غير لافتة للنظر (بدون إضافات كبيرة/فاخرة، إلخ) والتي، اعتبارًا من اليوم، تفشل في البدء لأن Ember يستهلك كل ذاكرة الوصول العشوائي التي يمكنه العثور عليها، وكل ذاكرة التبديل، ويجعل الجهاز غير مستجيب. سمح إضافة 2 جيجابايت أخرى من ذاكرة التبديل بإنهاء عملية البدء، مع ذروة استخدام ذاكرة التبديل تبلغ حوالي 2.5 جيجابايت.
يا للأسف، هذا على قائمة @david للتحقيق.
5 إعجابات
@david كان يحقق، ونحن نؤكد أنه حسب الوضع الحالي، فإن 2 جيجابايت كافية لإعادة بناء دوكر، ولكنها غير كافية لعمل مُحدِّث الويب.
إحدى الأفكار التي طرحتها هي إيقاف جميع عمليات روبي أثناء مُحدِّث الويب لتوفير 300-500 ميجابايت إضافية، مما سيوفر مساحة كافية لتجميع الأصول مسبقًا.
نهج طويل الأمد من المرجح أن نتبعه للمستضيفين الذاتيين هو شحن حاويات مُهيأة مسبقًا، وهي علبة باندورا لأن كيف يمكن لمُحدِّث الويب أن يحقق ذلك. لا نريد ربط مقابس دوكر…
إنه بالتأكيد موقف صعب.
إعجابَين (2)
حسنًا، لم يكن كذلك بالنسبة لي.
هل تتم المقارنة بين التثبيت الأساسي النقي مقابل مواقف العالم الحقيقي؟
بالتأكيد، إنه ليس متسقًا تمامًا. حتى مع إغلاق كل شيء آخر، قد يفشل الأمر.
للأسف، نحن نخوض معركة خاسرة ضد أدوات بناء JavaScript الحديثة هنا. تم تصميم كل شيء للتشغيل على ذاكرة وصول عشوائي بسعة 8 جيجابايت أو أكثر على أجهزة المطورين الحديثة، وليس على خوادم افتراضية خاصة بسعة 1 جيجابايت 
لدينا بعض الحلول في أذهاننا. على سبيل المثال: توفير أصول مُعدة مسبقًا يمكن تنزيلها تلقائيًا. التحدي الكبير الذي نواجهه هو المكونات الإضافية، لأنها تختلف في كل موقع، وحاليًا تم دمجها بإحكام في البناء الأساسي.
ولكن في الوقت الحالي، يجب أن يكون إعادة بناء سطر الأوامر بالكامل معدل نجاح أعلى من تحديث واجهة المستخدم الرسومية.
8 إعجابات
مثل Jagster، فإن 2 جيجابايت من ذاكرة الوصول العشوائي + 2 جيجابايت من مساحة التبديل ليست كافية في الواقع لإعادة بناء دوكر التي تعمل عبر سطر الأوامر. بالتحقق أكثر، فإن الإضافات الوحيدة في هذا التثبيت هي docker_manager و discourse-prometheus - لا يتوقع أن يضع أي منهما حملاً غير متوقع على ember.
إذا كان يجب تغيير الحد الأدنى للمواصفات، فسيكون ذلك سيئًا، ولكنه سيكون أفضل بكثير من الوضع الحالي، حيث تتعطل الأجهزة بشكل غير متوقع عند كل ترقية.
7 إعجابات
إذا كان الأمر كذلك، أعتقد أنه لا يزال من الأفضل زيادة المواصفات الموصى بها قليلاً. شخصيًا، لا أمانع حقًا في إضافة 2 (أو حتى 4) جيجابايت أخرى من الـ swap إذا كان ذلك يجعل عمليات إعادة البناء أكثر موثوقية - على الأقل طالما أن العمليات اليومية لا تزال جيدة مع 2-4 جيجابايت من ذاكرة الوصول العشوائي (للمجتمعات الصغيرة والمتوسطة الحجم).
إعجابَين (2)
بالفعل فشل التثبيت الأولي في تثبيتي الأخير على جهاز 4c 4g. اقترح Ed إنشاء ملف مبادلة. وجدت الموضوع لإنشاء مبادلة وأنشأت مبادلة بحجم 4 جيجابايت. الآن كل شيء يعمل كما هو متوقع في تحديث/ترقية الويب أو سطر الأوامر.
في رأيي، قد نحتاج فقط إلى قبول أن ديسكورس يتطلب ذاكرة وصول عشوائي أكبر مما كان عليه في السابق.
3 إعجابات
ألن يكون zram منطقيًا؟
لقد قمنا للتو بتطبيق هذا الالتزام والذي نأمل أن يحسن الوضع. يرجى إخبارنا بكيفية سير الأمور! (سيتم تطبيقه على الاختبارات التي نجحت في غضون 30 دقيقة تقريبًا)
عند الاختبار باستخدام حاوية docker محدودة الذاكرة محليًا، يمكنني الآن الحصول على بناء ناجح باستخدام -m 1600m. قبل هذا التغيير، كان الحد الأدنى الذي يمكنني تحقيقه هو -m 3000m.
12 إعجابًا
لقد أجريت إعادة بناء تجريبية (تثبيت جديد)، والتي تمت دون مشاكل. الآن هذه الآلة لديها 4 جيجابايت من ذاكرة الوصول العشوائي (Hetzner CAX11) وملف مبادلة بنفس الحجم، لذلك فهي بالتأكيد أقل تقييدًا من الإعداد 2+2 جيجابايت المذكور أعلاه. ومع ذلك، كان استخدام المبادلة ضئيلًا خلال عملية البناء بأكملها، وكان الحد الأقصى لاستخدام ذاكرة الوصول العشوائي الذي رأيته حوالي 3.1 جيجابايت. وفي معظم الأوقات، ظل حول 2 جيجابايت، لذلك لا يبدو الأمر سيئًا للغاية (كان وقت البناء كما هو تقريبًا، أي حوالي 8 دقائق).
4 إعجابات
أود إجراء بعض التجارب المضبوطة، مع تثبيتات وإعادة بناء نظيفة، على مجموعة متنوعة من الإعدادات، وبشكل خاص أود رؤية الفرق (إن وجد) في التشغيل مع تجاوز الذاكرة (vm overcommit)، لكنني أخشى أنني لم أملك الوقت الكافي.
(بدون تجاوز الذاكرة، فإن عملية كبيرة تقوم بالانقسام (fork) سيكون لها زيادة فورية في استهلاك الذاكرة قد تكون قاتلة، ولن تظهر على مراقب يتم استطلاع حالته. حتى مع تجاوز الذاكرة، قد تكون زيادة الذاكرة سريعة بما يكفي لعدم الظهور في الاستطلاع، سواء كان htop أو vmstat أو أي شيء آخر.)
لا أعتقد أنني رأيت شخصًا ما يذكر ما إذا كان يقوم بالتشغيل مع تجاوز الذاكرة أم لا، على الرغم من أنه في رأيي يعد جانبًا مهمًا من تكوين المضيف.
إعجاب واحد (1)
أراهن أن معظم الناس لا يفعلون ذلك.
لقد قمت بتعيينه تلقائيًا في تثبيتاتي. ما زلت أحصل على هذا التحذير بشأنه.
لا علاقة لـ Overcommit هنا، لأن المشكلة ليست في قتل العمليات مبكرًا بسبب نفاد الذاكرة (OOM-killed)، بل هي مجرد محاولة حشر عشرة أرطال من الذاكرة المخصصة في كيس بسعة خمسة أرطال.
ليس من الممكن عمليًا تشغيل إعادة بناء Discourse مع overcommit_memory=2، لأن Ember (من بين أشياء أخرى، بلا شك) تخصص مسبقًا كميات هائلة من الذاكرة الافتراضية (على ما أذكر، حوالي 80 جيجابايت هو ما رأيته)، لذلك سيؤدي ذلك دائمًا إلى مخالفة أي إعداد معقول لـ overcommit_ratio. لن يساعد تعيين overcommit_memory=1 أيضًا، لأنه مرة أخرى، المشكلة ليست في أن مدير الذاكرة الافتراضية (VMM) يقتل العمليات بشكل مفرط، بل هي إدارة ذاكرة سيئة للغاية من مترجم Ember.
إعجاب واحد (1)
لست متأكدًا من أنني أتفق تمامًا مع تحليلك! حسب فهمي، يسمح الإفراط في التخصيص للعمليات بتخصيص ذاكرة لا تستخدمها. الأمر لا يتعلق فقط بسلوك قاتل نفاد الذاكرة (OOM-killer). ولكن كما قلت، أود إجراء بعض التجارب المضبوطة، فهذه طريقة أفضل لمعرفة ما يحدث فرقًا وما لا يحدث.
لدي 4 جيجابايت من الذكرة العشوائية والعديد من الإضافات (لا أعلم عن وجود ملف تبادل). كم عدد الإضافات لديك وهل تعتقد أن 4 جيجابايت من الذكرة العشوائية تكفي؟
صحيح جزئيًا، ولكن حتى مع ذلك، فهو غير ذي صلة، لأن المشكلة التي تتم مناقشتها في هذا الموضوع هي تخصيص العمليات للذاكرة التي تستخدمها، واستخدامها لمزيد منها مما هو متاح للنظام، مما يتسبب في انقطاعات مرئية للعملاء.
هل يمكنك تأكيد أن متطلبات الذاكرة بعد تغييرات @david قد انخفضت؟ يجب أن نكون في وضع معقول الآن.
القفزة الكبيرة التالية ستكون التجميع المسبق للأصول المجمعة مسبقًا والموزعة، إنها تغيير كبير جدًا للوصول إلى هناك ولكنه سيمحو مجموعة كبيرة من العمل من الإنترنت بمجرد الانتهاء.
إعجابَين (2)
مع كامل احترامي، لست متأكدًا من ذلك. لقد رأيت سجلات تظهر فشلًا في الانقسام. نقول في هذا الموضوع إنها “متطلبات الذاكرة” ولكن هذا - في رأيي - يشمل تكتيكات النواة للذاكرة الافتراضية. من الواضح أن تجربة أو ثلاث ستظهر ما إذا كنت على حق أم لا بشأن التجاوز.
كان ذلك إصدارًا جديدًا بدون أي إضافات. يمكنني محاولة إصدار آخر مع تمكين بعض الإضافات وربما تعطيل التحويل مؤقتًا للتأكد من أن البناء ينجح (ربما يستغرق الأمر بضعة أيام حتى أجد وقتًا، على الرغم من ذلك).
إعجابَين (2)