ليس مشكلتي، ولكن هل هذا يعني أنه لا يوجد شيء آخر؟
إعجاب واحد (1)
ربما لم يكن ذلك عن قصد، ولكن قد يكون من المفيد تدقيق محتويات المضيف بحثًا عن عمليات تعدين العملات المشفرة، وما إلى ذلك…
3 إعجابات
الخطوة 1: إصلاح مشكلة الأداء التي تم تحديدها بالفعل لاستخدام برنامج تشغيل vfs
7 إعجابات
حول هذا التبديل إلى overlay2 (من الناحية المثالية)، سأضطر إلى مسح التثبيت الحالي وإعادة تثبيت كل شيء. هذا لأن المضيف الذي أعمل عليه حاليًا يدعم فقط fuse-overlayfs أو vfs وهما ليسا موصى بهما.
ومع ذلك، سيقومون قريبًا بتمكين KVMs التي تدعم overlay2.
لذا، ستكون نيتي استخدام ذلك، بدلاً من fuse-overlayfs غير المقترح أيضًا.
الآن، في تطبيق Discourse نفسه، يمكنني أخذ نسخ احتياطية. ماذا تقوم هذه النسخة الاحتياطية بالضبط؟
هل سأفقد أي شيء من منتدى Discourse الحالي (أعني أي شيء مثل الرسائل، الدردشات، الإعدادات، المستخدمين، الصور التي تم تحميلها، إلخ) إذا أخذت نسخة احتياطية، وأعدت تثبيت Discourse جديد على خادم جديد، ثم بعد الإعداد الأولي لـ Discourse، قمت بالكتابة فوقه بالنسخة الاحتياطية؟
هل سينجح ذلك؟
نعم، هذا سينجح.
الشيء الوحيد الذي لم تذكره هو التأكد من أن لديك نفس الإضافات (plugins) على Discourse الجديد كما لديك على الحالي. إذا أعدت استخدام ملف app.yml الخاص بك، فسيكون كل شيء على ما يرام أيضًا.
3 إعجابات
حسنًا، شكرًا على لفت انتباهي إلى ذلك، أراهن أنني كنت سأصطدم به مباشرة.
حسنًا إذًا…
- أخذ نسخة احتياطية في منطقة إدارة Discourse
- فقط من أجل السلامة، بالطبع، أخذ نسخة احتياطية من الخادم
- أخذ نسخة من ملف yaml
- تفريغ الخادم
- إعداد خادم جديد بتقنية مدعومة
- تثبيت Docker مع مشغل تخزين مناسب
- إعادة بناء نسخة Discourse جديدة بالكامل باستخدام ملف yaml الذي تم نسخه احتياطيًا
- استعادة Discourse من النسخة الاحتياطية
متفاجئ قليلاً لأن النسخة الاحتياطية بحجم 19.2 ميجابايت فقط.
لقد قمنا بالفعل بتحميل العديد من الصور وما إلى ذلك… ولكن أعتقد أن كل ما يمكنني فعله هو المحاولة.
سأقوم بذلك في عطلة نهاية الأسبوع وسأبلغكم إذا كان تغيير مشغل التخزين قد أحدث فرقًا.
إعجاب واحد (1)
تحقق من أن هذا مضبوط:
إعجاب واحد (1)
يرجى ملاحظة أن هذا الإعداد المحدد ينطبق فقط على النسخ الاحتياطي المجدول، وليس على النسخ الاحتياطي اليدوي. مع النسخ الاحتياطي اليدوي، تحصل دائمًا على خيار صريح.
إعداد آخر لتمكينه هو تضمين الصور المصغرة في النسخ الاحتياطي
@smileBeda أود تأجيل #4 حتى يعمل كل شيء بشكل جيد.
3 إعجابات
بالفعل تم تحديده، ولكن لم يتم تحديد تضمين الصور المصغرة التي تم إنشاؤها في النسخ الاحتياطية. سيؤدي تعطيل هذا إلى تقليل حجم النسخ الاحتياطية، ولكنه يتطلب إعادة خبز لجميع المشاركات بعد الاستعادة..\n\n@RGJ … صحيح، فكرة جيدة، سيتطلب الأمر خطوات إضافية حيث سأحتاج إلى إنشاء خادم تحت كيان جديد، ولكنه أمر بسيط مقارنة بالمخاطر.\n\nسأسمح بتشغيل النسخ الاحتياطي المؤتمت للحصول على جميع البيانات فيه، حيث أفهم أن النسخ الاحتياطي اليدوي لن يتضمن الصور وما إلى ذلك.\n\nشكراً…
هذا افتراض غير صحيح.
عند إنشاء نسخة احتياطية يدوياً، تحصل على خيار في نافذة منبثقة إذا كنت تريد عمل نسخة احتياطية لقاعدة البيانات فقط، أو تضمين التحميلات.
عند إنشاء نسخ احتياطية مجدولة، يحدد إعداد backup with uploads ذلك.
4 إعجابات
حسناً، لقد أسأت فهم ما ذكرته سابقاً يرجى ملاحظة أن هذا الإعداد المحدد ينطبق فقط على النسخ الاحتياطي المجدول، وليس على النسخ الاحتياطي اليدوي.
شكراً…
إعجابَين (2)
مرحباً، أنا أعيد استخدام هذا الموضوع لأنه لا يزال مفتوحًا ونواجه نفس المشكلة بعد الترحيل إلى خادم افتراضي جديد. تمامًا كما يقول الجميع، لم يستغرق الأمر مني أكثر من 20 دقيقة لإعادة بناء Discourse الخاص بنا، ولكن في هذا الخادم الجديد يستغرق الأمر ساعات، وهو يمتلك ضعف الموارد مقارنة بالخادم السابق. 
لقد تحققت من مواضيع أخرى حول الترقيات التي تستغرق ساعة على Meta ولكني لا أستطيع تحديد المشكلة في مشكلتنا:
الخادم: 4 جيجابايت ذاكرة وصول عشوائي، 2 وحدة معالجة مركزية، 50 جيجابايت قرص.
مساحة المبادلة (Swap):
/$ free
total used free shared buff/cache available
Mem: 3911740 507208 2318476 268 1384032 3404532
Swap: 4095976 45472 4050504
Docker:
/$ sudo docker info
Client:
Version: 26.1.3
Context: default
Debug Mode: false
Server:
Containers: 3
Running: 0
Paused: 0
Stopped: 3
Images: 3
Server Version: 26.1.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version:
runc version:
init version:
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.8.0-31-generic
Operating System: Ubuntu 24.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 3.731GiB
Name: podkasts
ID: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
يبدو طبيعيًا بالنسبة لي ولكن ربما فاتني شيء ما. أين يمكننا البحث أيضًا؟
ربما يكون هناك جار صاخب يجعل جهازك الافتراضي الجديد أبطأ من الجهاز القديم لأنه يستخدم كل وحدة المعالجة المركزية التي لا تحصل عليها؟
إعجاب واحد (1)
نعم، شكراً لك، من المطمئن أن مسؤولاً ذا خبرة مثلك لا يرى أي شيء واضح في المعلومات أعلاه. ونعم، نحن نبدأ في النظر إلى الخادم الفعلي وجوارنا الافتراضي. على الأقل يعمل المنتدى دون مشاكل ملحوظة للمستخدمين. نحن نواجه هذه المشكلة الخطيرة في الأداء فقط مع إعادة البناء. استغرق منا الأمر 4 ساعات لإعادة البناء بالأمس. 
إعجاب واحد (1)
إذا واجهت هذه المشكلة، سأفتح نافذتين أو ثلاث نوافذ طرفية. واحدة لتشغيل إعادة البناء، وواحدة لتدوين الوقت المنقضي وتدوين أماكن حدوث التأخيرات الطويلة بين تحديثات السجل، والنافذة الأخيرة للاحتفاظ بسجل لنشاط الجهاز: ربما تشغيل vmstat 5
عندما تصل إلى نقطة لا يتم فيها تحديث السجل لفترة طويلة بشكل مثير للشك، قم بتدوين النشاط الذي أبلغ عنه vmstat.
انشر مقتطفات مناسبة من السجل مع ملاحظاتك ومخرجات vmstat المقابلة هنا.
من المحتمل جدًا أن تكون أجزاء معينة من إعادة البناء هي التي تستغرق وقتًا: الشيء الذي يجب فعله هو معرفة الأجزاء، ومعرفة ما يفعله الجهاز في تلك الأوقات.
ربما أقوم أيضًا بأخذ لقطة لنشاط الجهاز باستخدام ps auxf أثناء التوقفات أيضًا.
4 إعجابات
شكراً لك، هذه نصيحة جيدة جداً. في المرة القادمة التي نحتاج فيها إلى إعادة البناء، سنفعل ذلك بهذه الطريقة.
إعجابَين (2)