Ganze Maschine hängt sich beim Upgrade auf.

[uwe_keim]

Seitdem ich die KI-Plugins ausprobiert habe (und sie später wieder entfernt habe), hängt sich meine Maschine bei /admin/upgrade komplett auf.

Nicht jedes Mal, aber ungefähr 80% der Zeit.

Normalerweise friert meine gesamte EC2-Instanz ein und ich muss einen Hard-Reboot über die AWS EC2 Web-UI durchführen.

Heute hängt sie sich wieder auf. Zu meiner Überraschung friert sie nicht komplett ein. Beim Öffnen der Root-URL wird nun angezeigt:

Ups

Die Software, die dieses Diskussionsforum antreibt, ist auf ein unerwartetes Problem gestoßen. Wir entschuldigen uns für die Unannehmlichkeiten.

Detaillierte Informationen über den Fehler wurden protokolliert und eine automatische Benachrichtigung generiert. Wir werden uns darum kümmern.

Es sind keine weiteren Maßnahmen erforderlich. Wenn die Fehlerbedingung jedoch weiterhin besteht, können Sie zusätzliche Details, einschließlich der Schritte zur Reproduktion des Fehlers, angeben, indem Sie ein Diskussionsthema in der Feedback-Kategorie der Website veröffentlichen.

Ich werde sie jetzt erneut neu starten und die üblichen sudo ./launcher rebuild app-Sachen machen, die sie bisher behoben haben. Daumen drücken, dass es heute wieder funktioniert.

Meine Frage

Kann mir jemand Hinweise geben, wo ich in Logdateien oder ähnlichem nachsehen kann, um zumindest eine Fehlermeldung zu erhalten, warum die Hänger auftreten?

[sam (Sam Saffron)]

@uwe_keim

die KI-Plugins

Das offizielle KI-Plugin?

Ich würde dies von der Konsole aus ausführen und sehen, wo es hängen bleibt, teile die Protokolle.

[uwe_keim]

Ja, das offizielle Plugin.

Ich habe es deinstalliert, indem ich die Plugins erneut aus app.yml entfernt und dann neu erstellt habe. Vielleicht reicht das nicht aus?

@sam

Ich würde das ausführen

Was ist mit „das“ gemeint? Das sudo ./launcher rebuild app?

[merefield (Robert)]

Was sind die Spezifikationen Ihres Servers?

Online-Upgrades erfordern meiner Meinung nach heutzutage mindestens einen 4-GB-Server + 2 GB Swap.

[uwe_keim]

Ich verwende eine AWS EC2 „t2.medium“ mit 2 vCPUs und 4 GiB RAM.

Die HDD ist 100 GiB mit 60 GiB freiem Speicherplatz.

Wenn es hilft, kann ich „t2.medium“ auf einen größeren Instanztyp aufrüsten.

Ich bin nur verwirrt, dass diese Einrichtung (jahrelang) einwandfrei lief, bevor ich das offizielle KI-Plugin testete, und erst seitdem nach dessen Entfernung diese Hänger während des Upgrades auftreten.

[Ed_S]

@uwe_keim

Dieses Setup lief (jahrelang) solide, bevor ich das offizielle KI-Plugin getestet habe, und erst seitdem, nachdem ich es entfernt habe, treten diese Hänger während des Upgrades auf.

Etwas anderes hat sich geändert: die Version der Software, auf die Sie upgraden. Sie ist in letzter Zeit speicherhungriger geworden. Ich denke also, es könnte eines von beiden sein.

Ein temporäres und reversibles Upgrade auf eine Instanz mit mehr RAM ist wahrscheinlich der einfachste Weg, um zu testen, ob ein Speichermangel das Problem ist, obwohl es ein paar Neustarts kostet. Der andere Weg ist, Swap hinzuzufügen, was ebenfalls reversibel ist.

[pfaffman (Jay Pfaffman)]

Ich würde versuchen, Swap hinzuzufügen.

[uwe_keim]

Danke, Leute, ich werde googeln, wie das geht, und es dann tun .

Update 1

Ich habe jetzt 8 GiB Swap hinzugefügt:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

Ich werde hier ein Update posten, nachdem ich einige weitere Upgrades durchgeführt habe, ob dies geholfen hat.

Update 2

Habe gerade ein /admin/upgrade durchgeführt und die RAM-Auslastung überwacht:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

Und das Upgrade wurde erfolgreich durchgeführt. Hoffentlich bleibt das so.

Update 3

Mehrere Tage und Upgrades später habe ich nie wieder einen Hänger erlebt.

Ich denke also, dass der Swap die Lösung war. Nochmals vielen Dank an alle, die mir bei diesem Problem geholfen haben.

[Jagster (Jakke Lehtonen)]

Das ist zwar etwas am Thema vorbei, aber ich würde es wirklich gerne verstehen. Warum hat Swap, das 200 MB verbraucht hat, geholfen, als noch 2 GB RAM frei waren?

(Ich verstehe, dass in der Inch-Welt das SI-System verwirrend sein kann, weil es eine Skala von 10 verwendet, aber warum zum Teufel Mi? Ich kann Gi irgendwie verstehen, wenn es eine Abkürzung für Giga ist, aber sollte Mega dann Me sein?)

[Firepup650 (Firepup Sixfifty)]

@Jakke Lehtonen

aber warum zum Teufel Mi? Gi kann ich irgendwie verstehen

Mi für Mibibytes, nehme ich an, und Gi für Gibibytes.

[Jagster (Jakke Lehtonen)]

Danke. Das wusste ich nicht, offensichtlich. Aber es ist Mebibyte

Und für andere, die es auch nicht wussten

Mebibyte

[Ed_S]

@Jagster

Das ist ein wenig am Thema vorbei, aber ich würde es wirklich gerne verstehen. Warum hat Swap, das 200 MB verbrauchte, geholfen, als noch 2 GB RAM frei waren?

Ich denke, das ursprüngliche Problem war wahrscheinlich, dass ein Prozess beendet wurde, weil der Maschine der Arbeitsspeicher ausging (Vorsicht vor dem OOM-Killer). Das Hinzufügen von Swap bedeutete, dass der Arbeitsspeicher nicht erschöpft war. Diese beiden Ausgaben von free erzählen möglicherweise nicht die ganze Geschichte, es sei denn, sie wurden sehr sorgfältig im Moment der größten Belastung der Maschine aufgenommen. Ich denke, der interessante Punkt ist die maximale Swap-Nutzung.

Aber es gibt auch die Frage nach dem Kernel-Tuning, wie in
MKJs Opinionated Discourse Deployment Configuration
erwähnt, das ich richtig eingestellt habe, aber das vielleicht viele Leute nicht richtig eingestellt haben.

@mcdanlj

Kernel-Konfiguration

Redis (eine der Schlüsselkomponenten, auf denen Discourse aufbaut) empfiehlt dringend, transparente riesige Seiten zu deaktivieren, und ich erlaube auch Memory Overcommit.

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system

Es ist erwähnenswert, dass Memory Overcommit nicht viel mit Redis zu tun hat. Redis ist nur nett genug, um darauf hinzuweisen, dass es richtig eingestellt sein sollte.

[uwe_keim]

Habe gerade ein weiteres /admin/upgrade gestartet und hatte eine Shell geöffnet, um tree -h etwa jede Sekunde manuell aufzurufen.

Die höchsten Speicherverbrauchswerte, die ich finden konnte, waren diese:

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

Das Upgrade war erfolgreich.

[Jagster (Jakke Lehtonen)]

Also sind 4 GB nur am Rande zur Bauzeit, wenn wir davon ausgehen, dass der letzte Screenshot den stressigsten Moment zeigt.

Und das ist eine weitere Sache, die ich nicht verstehen kann: Warum haben andere wenig Speicher und ich, der viele Plugins und Komponenten verwendet, hatte keine Probleme Was macht diesen Unterschied aus?

Und ich habe hatte verwendet, weil ich heutzutage 8 GB wegen KI habe (und für mich war der Preisunterschied nicht so wichtig, aber das ist eine andere Geschichte).

Sollte dieser Thread woanders hin verschoben werden oder sehen wir dies als Erklärung, warum die Verwendung von Swap geholfen hat?

Wie auch immer. Für andere Anfänger ist dies ein Beispiel, in dem wenig über wenig Speicher und die Gründe dafür gesprochen wird:

Problem with Upgrade [error 137]

For standard install site have this error log for most recent upgrade: ******************************************************** *** Please be patient, next steps might take a while *** ******************************************************** Cycling Unicorn, to free up memory Restarting unicorn pid: 545 Waiting for Unicorn to reload. Waiting for Unicorn to reload.. Waiting for Unicorn to reload... Waiting for Unicorn to reload.... Waiting for Unicorn to reload..... Waiting for Unicorn to reloa…

Das ist eine stark FAQ-Frage, wenn das Upgrade fehlschlägt. Aber der Grund dafür wird selten erklärt.

[Ed_S]

@Jagster @uwe_keim bitte berichtet die Ausgabe dieser Befehle

cat /proc/sys/vm/overcommit_memory
cat /sys/kernel/mm/transparent_hugepage/enabled

Auf meinen Systemen habe ich

# cat /proc/sys/vm/overcommit_memory
1
# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

[uwe_keim]

$ cat /proc/sys/vm/overcommit_memory
0

und

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

[Ed_S]

Danke @uwe_keim – ich gehe davon aus, dass diese Kernel-Tunables der Grund dafür waren, dass Sie Swap hinzufügen mussten, auch wenn er nicht zu genutzt schien. (Dasselbe würde gelten, wenn Sie viel RAM hinzufügen mussten, da der gesamte verfügbare Speicher RAM + Swap ist.)

[uwe_keim]

Ich kann die Servereinstellungen jederzeit ändern, wenn Sie dies empfehlen.

[Jagster (Jakke Lehtonen)]

root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

[Ed_S]

@uwe_keim

Server-Einstellungen jederzeit ändern, wenn Sie es empfehlen

Das empfehle ich!

Dies behebt das Problem für zukünftige Neustarts (beachten Sie, dass Dateien überschrieben werden, ohne den aktuellen Zustand zu prüfen):

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system