Hallo zusammen, ich hoffe auf Hilfe!
Hat das schon mal jemand erlebt?
./launcher rebuild app läuft, kommt bis zu diesem Punkt und hängt dann hier fest.
Jetzt tut es etwas, aber extrem langsam. Ich betreibe das Forum seit 3 Jahren über ein selbst installiertes Digital Ocean Droplet, aber das ist neu und verursacht viel Ausfallzeit. Gibt es eine Möglichkeit, das zu glätten? Liegt es an den Bildern im Forum oder an etwas anderem?
Können Sie bitte eine weitere SSH-Sitzung öffnen und versuchen, herauszufinden, welche Migration Probleme verursacht?
Etwas wie ps aux | grep postgres sollte den Anfang davon zeigen.
Ich bin kein Linux-Experte (oder ehrlich gesagt nicht einmal ein Amateur), aber ich werde es versuchen.
Mein Tipp ist, dass der Speicher zur Neige geht. Sie können versuchen:
free -h
Vielleicht auch:
du -hs /var/discourse/shared/standalone/*
Arbeitsspeicher (RAM) oder Festplattenspeicher?
Ich denke, es sollte von beidem reichlich vorhanden sein – der Droplet ist: 8 GB Arbeitsspeicher / 4 Intel vCPUs / 160 GB Festplatte + 200 GB / Ubuntu 18.04.3 (LTS) x64
Ist es „sicher“, eine weitere SSH-Sitzung zu öffnen und diese auszuführen, während dieser db:migrate-Prozess noch läuft?
Wenn ich Sie wäre, würde ich damit beginnen, einen neuen VPS mit einem Betriebssystem zu erhalten, das noch aktiven Support hat.
Ja.
Okay - bitte verstehe, dass ich KEIN Linux-Experte bin - dein Beitrag deutet an, dass der aktuelle Ubuntu-Build total veraltet ist etc.?
Ja, das Betriebssystem stammt vom April 2018 und wurde 5 Jahre lang unterstützt, das endete also vor über 6 Monaten.
Ich schätze die Informationen.
Als jemand, der offen zugibt, ein Amateur zu sein, der sein Bestes gibt – gibt es Empfehlungen, was ich als Nächstes tun sollte?
Die db:migrate ist fehlgeschlagen – die Meldung lautete:
client_loop: send disconnect: Connection reset
Nachdem ich mich wieder angemeldet habe, haben Sie ganz Recht:
Neue Version ‘20.04.6 LTS’ verfügbar.
Führen Sie ‘do-release-upgrade’ aus, um darauf zu aktualisieren.
In Anbetracht der Tatsache, dass mein Forum derzeit nicht verfügbar ist, kann ich das Upgrade sicher durchführen und mich dann um die Reparatur des Forums kümmern, oder sollte ich zuerst versuchen, es wieder online zu bringen?
Das ist ein SSH-Fehler…
Haben Sie vor dem Upgrade ein Backup erstellt? Wenn ja, wäre es am einfachsten, einen brandneuen Server mit Ubuntu 22 zu erhalten, Discourse zu installieren und das Backup wiederherzustellen.
Leider hat einer meiner Administratoren auf den Upgrade-Button auf der Website gedrückt, und es scheint fehlgeschlagen zu sein und alles kaputt gemacht zu haben. 
Das letzte Backup wurde gestern gemacht - also nicht allzu schlimm.
Ich nehme an, ein Upgrade auf den bestehenden Server würde die bestehende Installation überschreiben?
(Danke für deine Geduld @RGJ übrigens)
Schwer zu sagen, aber da die Dinge fehlschlagen, würde ich kein Risiko eingehen. Zumindest nicht, bevor ich sichergestellt habe, dass das Backup an einem sicheren Ort aufbewahrt wird.
Es besteht eine gute Chance, dass Sie eine neue VM hochfahren, den Container stoppen (es scheint, dass er sowieso nicht läuft) und dann alles auf den neuen Server rsyncen und es dort erneut versuchen können. Damit können Sie wahrscheinlich wieder betriebsbereit sein, ohne Daten zu verlieren.
Das klingt alles so einfach, aber Mann, ich fühle mich hier überfordert. Es läuft derzeit auf einem Digital Ocean Droplet. Also, eine neue VM hochfahren – ist das ein geladener Satz? Auf demselben Droplet? Auf einem neuen? 
Ein VM ist der gebräuchliche Begriff für das, was DigitalOcean eine Droplet nennt.
Es scheint, als ob Sie sich mein Profil ansehen und über Managed Hosting nachdenken möchten 
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 zeigt, dass der discourse [local] delete 100% CPU verbraucht. Das Droplet hat 8 GB RAM, und derzeit wird weniger als 1 GB verwendet (Puffer nicht mitgerechnet).
Das Betriebssystem ist veraltet, aber das erscheint mir sehr seltsam. Es gibt reichlich RAM und Festplattenspeicher, und diese Postgres-Löschaufgabe läuft seit über 12 Minuten. Es gibt weniger als 600.000 Beiträge und weniger als 4.000 Benutzer, daher ist die Datenbank nicht riesig. Oh. Warte. Das Verzeichnis postgres_data ist 28 GB groß.
Ich habe VACUUM VERBOSE ANALYZE; ausgeführt.
Ich habe Folgendes getan:
discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter;
checkpoints_timed | checkpoints_req
-------------------+-----------------
6 | 20
Ich versuche jetzt, gleichzeitig neu zu indizieren. Vielleicht helfen das Vacuum und die Neuindizierung.
Danke, Jay. Lass mich wissen, wenn du etwas von mir brauchst.
Bitte teile die gesamte SQL-Abfrage, die lange läuft.
Wo finde ich das?
Die Migration gibt keine Protokolle aus. Die letzte Zeile im Rebuild ist
I, [2023-12-04T22:33:33.759401 #1] INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'
Ich arbeite an einem vollständigen Protokoll für das, das ich gerade neu gestartet habe.
Geben Sie den Container ein, wechseln Sie zum postgres-Benutzer, geben Sie psql ein und führen Sie aus
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;