ترقية 3.1.x إلى 3.2.0 تعلق/تفشل على نسخة 1 جيجابايت

تثبيت
22

حسنًا، يمكنني فهم ذلك. ألن يكون من الممكن تبسيط عملية التمهيد/التجميع لتستغرق وقتًا أطول (وحدة المعالجة المركزية/التسلسل) ولكن ضمن موارد محدودة (أي ذاكرة الوصول العشوائي)؟

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

أعتقد أن هذه ستكون فكرة رائعة. وأحد الأسباب هو هذا: إذا لم يتمكن المرء من إعادة البناء على خادم صغير، فلن يتمكن من التثبيت على خادم صغير. وإذا قام المرء بالتثبيت على خادم متوسط الحجم، فلن يقوم بإنشاء ملف المبادلة الذي ستكون هناك حاجة إليه على الخادم الصغير. (من الناحية المثالية، سيقوم برنامج التثبيت بإنشاء ملف المبادلة على أي حال، وسيقوم أيضًا بتعيين تعديلات النواة التي يجب تعيينها.)

24

هذه أيضًا فكرة رائعة. بنفس الطريقة التي تراقب بها عملية هندسة البرمجيات بشكل مثالي أوقات الإنشاء، لأنه بخلاف ذلك تزداد أوقات الإنشاء باستمرار، بالنسبة لـ Discourse، ستختبر العملية وتراقب بشكل مثالي إمكانية التثبيت على مثيلات صغيرة. اجعلها هدفًا.

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

لقد جربت إنشاء صور مُشغّلة ذاتيًا تقوم بترحيل وتجميع الأصول مسبقًا عند التشغيل (مع إعدادات بيئة لتخطي تلك المهام). يعمل هذا بشكل جيد في الغالب (ليس كثيرًا للمواقع الضخمة وللأشياء التي تعتمد على حدوث التشغيل في وقت معين).

ومع ذلك، فإن هذه تعتمد على وجود redis و postgres.

مع تثبيت قياسي إلى حد كبير مكون من حاويتين، قد يكون من الممكن جعله يعمل بشكل جيد في الغالب.

أوه، ولكن تجميع الأصول مسبقًا هو على ما أعتقد الخطوة التي تسبب المشاكل. . .

26

أنا أقرأ عن ترقية Ember 5 هذه التي تشق طريقها عبر النظام. ما هو التأثير الذي يمكن أن تحدثه على موارد البناء؟

27

أعتقد أن الوثائق بحاجة إلى تحديث، discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub

  • الحد الافتراضي للذاكرة العشوائية 1 جيجابايت يعمل بشكل جيد لمجتمعات Discourse الصغيرة.

1 جيجابايت لم يعد خيارًا. الحد الأدنى المطلوب هو 2 جيجابايت لبناء Discourse.

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

لدي مجموعة من المواقع التي قمت بترقيتها مؤخرًا بذاكرة وصول عشوائي (RAM) بسعة 1 جيجابايت. لقد قمت بزيادة مساحة التبديل (swap) الخاصة بها إلى 3 أو 4 جيجابايت.

بالتأكيد لا أوصي بذلك، ولكن بالنسبة لبعض الأشخاص يمثل ذلك حاجزًا كبيرًا للتكلفة ويتمكنون من المضي قدمًا. ولكن ربما يكون “يعمل بشكل جيد” مبالغة.

3 إعجابات
29

نعم، ربما حدد ذلك، 1 جيجابايت من ذاكرة الوصول العشوائي + 4 جيجابايت من مساحة التبديل. فشل مع مساحة تبديل 2 جيجابايت.

30

هل لديك أي إضافات؟ العديد من السمات؟

31

9 إضافات وسمة واحدة فقط. مرة أخرى، كل هذا العمل بشكل رائع حتى الإصدار 3.1.x على ذاكرة وصول عشوائي بسعة 1 جيجابايت مع مساحة مبادلة بسعة 2 جيجابايت (كان بطيئًا بعض الشيء، ربما استغرق إعادة البناء 20 دقيقة ولكنه نجح دائمًا)
محاولة الترقية إلى 3.2.0 فشلت باستمرار (انظر أعلاه).

32

نعم. بالتأكيد لا توجد إضافات بذاكرة وصول عشوائي (RAM) بسعة 1 جيجابايت. يبدو أن هذا شيء يجب إضافته إلى وثائق التثبيت.

أود أن أعرف ما إذا كان يعمل بدون الإضافات.

33

كاختصار شديد، يمكنني أن أرى لماذا تقول هذا، ولكن ألا توافق على أن تشغيل ديسكورس يعتمد على ذاكرة الوصول العشوائي + الذاكرة الافتراضية؟ 1+3 لا يختلف عن 2+2 من وجهة نظر التشغيل/عدم التشغيل.

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

ذاكرة الوصول العشوائي + الذاكرة الافتراضية هو الشيء الصحيح للتحقق منه واختباره. الذاكرة = ذاكرة الوصول العشوائي + الذاكرة الافتراضية.

بالمناسبة، إذا كان هناك شيء لا يعمل دون دليل واضح على سبب ذلك، وخاصة إذا كنت تشك في نقص الذاكرة، فمن المفيد التحقق من قاتل نفاد الذاكرة، المعروف أيضًا باسم OOM-killer. أوصي بـ

dmesg|egrep -i "memory|oom|kill"

تعديل: للراحة، سأضيف هذا إلى قائمة التشخيصات الفورية القياسية الخاصة بي:

cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
5 إعجابات
34

لقد واجهت نفس المشكلة، ولكن ليس أثناء الترقية، بل أثناء إجراء تثبيت جديد للإصدار 3.2.0.

أنا أستخدم AWS EC2، تمامًا مثل @RBoy.

أبحث عن حل لتثبيت الإصدار 3.1.5 بدلاً من 3.2.0، حيث لم يقدم المنتدى القديم أي مساعدة.

تحديث:
آسف، لقد وجدت هذا:

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

سأكون مهتمًا جدًا بمعرفة ما إذا كنت قادرًا على إجراء تثبيت نظيف للإصدار 3.1.5 باستخدام طريقة العلامة المذكورة في الرابط الخاص بك. يرجى الرد إذا قمت بتجربتها.

بالنسبة لتثبيت الإصدار 3.2.0 على نظام بحجم 1 جيجابايت، يمكنك تجربة هذا، قم بضبط حجم SWAP الخاص بك إلى 8 جيجابايت وانظر ما إذا كان ذلك سينجح. ربما سيكون بطيئًا للغاية ولكنه قد ينجح.

36

شكراً لتوجيهاتك القيّمة.

لقد أكملت مؤخرًا تثبيتًا جديدًا لإصدار Docker من Discourse 3.15 وأردت مشاركة مدى سهولة العملية، خاصة لأولئك الذين يستخدمون الطبقة المجانية من AWS EC2، مثلي.

إليك دليل موجز بناءً على تجربتي:

  1. انتقل إلى ملف تكوين Discourse الخاص بك الموجود في /var/discourse/containers/app.yml.

  2. في قسم params، قم بتحديث معلمة الإصدار لمطابقة إصدار Discourse المطلوب. على سبيل المثال:

    params:
  # ...
  ## Specify the Git revision for this container (default: tests-passed)
  version: v3.1.5 # Use the specific tag name here

  3. احفظ تغييراتك واخرج من المحرر. ثم، قم بتنفيذ الأمر التالي لإعادة بناء تطبيق Discourse الخاص بك:

    /var/discourse/launcher rebuild app

لقد نجحت العملية بسلاسة بالنسبة لي، مما يثبت أن الحفاظ على إعداد Discourse منخفض التكلفة أو حتى بدون ميزانية أمر ممكن تمامًا.

آمل أن يساعد هذا الدليل الآخرين الذين يتطلعون إلى إدارة تثبيتات Discourse الخاصة بهم بكفاءة وفعالية من حيث التكلفة.

إعجابَين (2)