أهلاً بالجميع، آمل الحصول على بعض المساعدة!
هل واجه أي شخص هذا من قبل؟
./launcher rebuild app قيد التشغيل، ويصل إلى هذه النقطة ويتوقف هنا.
الآن يقوم بشيء ما، ولكنه يقوم به ببطء شديد. لقد كنت أقوم بتشغيل المنتدى عبر قطرة مثبتة ذاتيًا على DigitalOcean لمدة 3 سنوات، ولكن هذا جديد ويسبب الكثير من وقت التوقف. هل هناك طريقة لتخفيف ذلك؟ هل الأمر يتعلق بالصور في المنتدى أم شيء آخر؟
هل يمكنك فتح جلسة SSH أخرى ومحاولة العثور على الهجرة التي تسبب المشكلة؟
شيء مثل ps aux | grep postgres يجب أن يظهر بدايتها.
لست خبيرًا في لينكس (أو بصراحة، حتى هاويًا) ولكني سأحاول.
نفاد الذاكرة هو تخميني. يمكنك تجربة
free -h
ربما أيضًا
du -hs /var/discourse/shared/standalone/*
الذاكرة (RAM) أم مساحة القرص؟
أعتقد أنه يجب أن يكون هناك الكثير من كليهما - القطرة هي: 8 جيجابايت ذاكرة / 4 معالجات Intel vCPUs / 160 جيجابايت قرص + 200 جيجابايت / Ubuntu 18.04.3 (LTS) x64
هل من “الآمن” فتح جلسة SSH أخرى وتشغيلها أثناء تشغيل عملية db:migrate هذه؟
لو كنت مكانك، لبدأت بالحصول على خادم افتراضي خاص جديد بنظام تشغيل لا يزال مدعومًا بنشاط.
نعم.
حسنًا - يرجى تفهم أنني لست خبيرًا في لينكس - هل يشير منشورك إلى أن إصدار أوبونتو الحالي قديم جدًا وما إلى ذلك؟
نعم، نظام التشغيل مؤرخ في أبريل 2018 وتم دعمه لمدة 5 سنوات، لذا انتهى دعمه منذ أكثر من 6 أشهر.
أقدر المعلومات.
بصفتي شخصًا يعترف بحرية بأنه هاوٍ يبذل قصارى جهده - هل لديك أي توصيات بشأن ما يجب أن أفعله بعد ذلك؟
فشل db:migrate - كانت الرسالة:
client_loop: send disconnect: Connection reset
عند تسجيل الدخول مرة أخرى، أنت على حق تمامًا:
الإصدار الجديد ‘20.04.6 LTS’ متاح.
قم بتشغيل ‘do-release-upgrade’ للترقية إليه.
بالنظر إلى أن منتداي معطل حاليًا، هل من الآمن إجراء الترقية، ثم القلق بشأن إصلاح المنتدى؟ أم يجب أن أحاول إعادة تشغيله أولاً؟
هذا خطأ SSH…\n\nهل قمت بعمل نسخة احتياطية قبل الترقية؟ إذا كان الأمر كذلك، فسيكون من الأسهل الحصول على خادم جديد تمامًا مع Ubuntu 22، وتثبيت Discourse واستعادة النسخة الاحتياطية.
للأسف، قام أحد مسؤولي النظام لدينا بالضغط على زر الترقية في الموقع، ويبدو أنه فشل ثم أفسد كل شيء. 
تم أخذ آخر نسخة احتياطية بالأمس - لذا ليس الأمر سيئًا للغاية.
هل يعني ذلك أن الترقية إلى الخادم الحالي ستمحو التثبيت الحالي؟
(شكرًا لصبرك @RGJ بالمناسبة)
من الصعب معرفة ذلك، ولكن بما أن الأمور تفشل، فلن تخاطر. على الأقل ليس قبل التأكد من أن النسخة الاحتياطية مخزنة في مكان آمن.
هناك فرصة جيدة لإمكانية تشغيل جهاز افتراضي جديد، وإيقاف الحاوية (يبدو أنها لا تعمل على أي حال) ثم استخدام rsync لنقل كل شيء إلى الخادم الجديد والمحاولة مرة أخرى هناك. يمكن أن يعيدك هذا على الأرجح إلى العمل دون فقدان أي بيانات.
يبدو كل شيء بسيطًا جدًا، لكن يا إلهي أشعر بأنني خارج نطاق خبرتي هنا. إنه يعمل حاليًا على قطرة رقمية. لذا فإن تشغيل جهاز افتراضي جديد - هل هذه جملة مشحونة؟ على نفس القطرة؟ على واحدة جديدة؟ 
المصطلح الشائع لجهاز افتراضي هو ما تسميه DigitalOcean “قطرة” (droplet).
يبدو أنك قد ترغب في إلقاء نظرة على ملفي الشخصي والنظر في الاستضافة المُدارة 
ystemd+ 7660 0.0 0.3 352060 28284 ? S 22:31 0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
systemd+ 7667 0.0 0.1 352588 9628 ? Ss 22:31 0:00 postgres: 13/main: checkpointer
systemd+ 7668 0.3 0.9 352060 78796 ? Ss 22:31 0:03 postgres: 13/main: background writer
systemd+ 7669 0.0 0.1 352060 13696 ? Ss 22:31 0:00 postgres: 13/main: walwriter
systemd+ 7670 0.0 0.1 352728 11892 ? Ss 22:31 0:00 postgres: 13/main: autovacuum launcher
systemd+ 7671 0.0 0.0 67996 5320 ? Ss 22:31 0:00 postgres: 13/main: stats collector
systemd+ 7672 0.0 0.0 352612 6640 ? Ss 22:31 0:00 postgres: 13/main: logical replication launcher
systemd+ 10900 82.0 3.8 487164 317728 ? Rs 22:33 10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901 0.0 0.1 353432 13804 ? Ss 22:33 0:00 postgres: 13/main: discourse discourse [local] idle
يُظهر htop أن مهمة discourse [local] delete هي التي تستهلك 100% من وحدة المعالجة المركزية. القطرة لديها 8 جيجابايت من ذاكرة الوصول العشوائي، وحاليًا أقل من 1 جيجابايت قيد الاستخدام (لا تشمل المخازن المؤقتة).
نظام التشغيل قديم، ولكن هذا يبدو غريبًا جدًا بالنسبة لي. هناك الكثير من ذاكرة الوصول العشوائي والقرص، ومهمة حذف postgres هذه قيد التشغيل منذ أكثر من 12 دقيقة. هناك أقل من 600 ألف منشور وأقل من 4 آلاف مستخدم، لذا فإن قاعدة البيانات ليست ضخمة. أوه. انتظر. دليل postgres_data هو 28 جيجابايت.
لقد قمت بتشغيل VACUUM VERBOSE ANALYZE;.
لقد فعلت هذا:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
أنا أحاول الآن إعادة الفهرسة بشكل متزامن. ربما سيساعد التفريغ وإعادة الفهرسة.
شكرًا جاي. أخبرني إذا كنت بحاجة إلى أي شيء مني.
يرجى مشاركة استعلام SQL الكامل للاستعلام طويل الأمد.
أين أجد ذلك؟
لا يقوم الترحيل بطباعة أي سجلات. السطر الأخير في إعادة البناء هو
I, [2023-12-04T22:33:33.759401 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
أنا أعمل على سجل كامل للسجل الذي أعدت تشغيله للتو.
أدخل الحاوية، قم بالتبديل إلى المستخدم postgres، أدخل psql وقم بتشغيل
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;