التركيب يستغرق وقتًا طويلاً، ثم ينتهي بدون بدء المنتدى فعليًا

أحاول بدء منتدى على محرك الحوسبة (Compute Engine) الخاص بـ GCP، وتشغيله على e2-micro. أعتقد أنه تم إنشاء ملف تبديل بحجم 2 جيجابايت عندما حاولت تشغيله لأول مرة.
لم يعمل حجم 10 جيجابايت لأنه كان قليلاً جدًا على ما أذكر، لذلك قمت بزيادته إلى 20 جيجابايت.
بعد تشغيل ./launcher rebuild app، بدأ في القيام بما يفعله. عندما كان يقوم بـ ...[@embroider/webpack، استغرق الأمر وقتًا طويلاً لدرجة أنني غادرت وعدت لاحقًا (بعد حوالي ساعتين).
وجدت أنه قد انتهى، لكن لم أتمكن من الوصول إلى منتدى، على الرغم من أنني قمت بربط سجل A الخاص بـ Namecheap بعنوان IP الخارجي للجهاز الافتراضي.
حاولت مرة أخرى، وهذه هي السجلات الكاملة (السجلات طويلة جدًا):
GCP e2-micro discourse logs.txt (176.7 KB)
ومع ذلك، فإن موقع Discourse الخاص بي لا يعمل. أحصل على:

502 Bad Gateway


nginx

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

الآن أحصل على:

504 Gateway Time-out


nginx

لقد نجحت! لا تهتم. لم أفعل شيئًا. لقد تم حل المشكلة بنفسها.

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

هل ينجح تقليل عدد عمال Unicorn إلى 1 في containers/app.yml للحفاظ على الذاكرة، ثم إعادة بناء التطبيق باستخدام ./launcher rebuild app بأي حال من الأحوال؟

أو يمكنك ترقية مثيلك مؤقتًا إلى e2-small أو أعلى، وإكمال إعادة البناء، ثم تغيير الحجم مرة أخرى إلى e2-micro.

إعجابَين (2)

لقد استغرقت إعادة البناء بالفعل ساعتين تقريبًا. لا أعتقد أنني أريد الانتظار هذه المدة للمرة الثالثة.
من ناحية أخرى، بريدي الإلكتروني لا يعمل الآن.

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

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

هل هذا تثبيت جديد؟ أم تثبيت جديد مع نقل الموقع القديم إلى الخادم الجديد؟

ساعتان تبدو طويلة جدًا في خبرتي.

تثبيت جديد. ربما لأن الخادم لديه 0.25 vCPU؟

إعجابَين (2)

قد يكون ذلك. إذا كنت لا تمانع سؤالي، فما هي مواصفات نظام وحدة معالجة الرسومات؟

منذ فترة طويلة جدًا. كان أحد الخوادم التي أديرها كمتطوع يعمل على وحدة معالجة رسومات أساسية بسعة 20 جيجابايت. وحتى مع حجم قاعدة البيانات الكبير عليها، فقد استغرق الأمر عادةً حوالي 15 دقيقة فقط.

في النهاية، أُجبر العميل على الانتقال إلى خادم أكبر بعد أن تعطل بشدة. في ذلك الوقت، لم ينتبهوا لتحذيراتي :warning: بأن الخادم سوف يتعطل لأنه لم يعد بإمكانه إعادة البناء عبر سطر الأوامر.

لذلك دفعوا لأحد الأعضاء هنا لنقله إلى خادم جديد بخطة 256 جيجابايت. كلفهم الكثير من وقت التعطل، حوالي 2.5 أسبوع لتجاهل المشكلة.

على الجانب الإيجابي، في الغالب يستمعون بشكل أفضل الآن للتحذيرات :warning: عند إعطائها.

أعتقد أنها 0.25 وحدة معالجة مركزية افتراضية و 1 جيجابايت من ذاكرة الوصول العشوائي. قام الإعداد بإنشاء ملف مبادلة بحجم 2 جيجابايت. جاء الخادم الأصلي بسعة تخزين 10 جيجابايت. لكن التثبيت قال إنه يحتاج إلى المزيد للمتابعة نظرًا لوجود حوالي 1.7 جيجابايت متبقية. لذلك قمت بزيادتها إلى 20 جيجابايت ولم أر أي تحذيرات متعلقة بالتخزين حتى الآن.