Seit der Migration meines großen Forums zu Discourse in diesem Jahr erlebe ich gelegentliche Abstürze, bei denen die Cloud-VM über SSH nicht erreichbar ist und eine Aufrufliste auf der virtuellen Konsole angezeigt wird. Die Abstürze treten ungefähr alle 3 bis 6 Wochen ohne bestimmtes Muster auf. Anfangs lief Discourse unter Clear Linux, da ich dieses System nutzte, um während der langen und intensiven Migration des alten Forums zu Discourse etwas mehr Leistung herauszuholen. Ich begann jedoch zu vermuten, dass Clear Linux aufgrund all seiner obskuren Leistungsoptimierungen möglicherweise weniger stabil war, daher migrierte ich mein Discourse etwa zur Zeit der Veröffentlichung vor etwa 6 Wochen auf Debian 12 Bookworm.
Leider hatte das Debian-System heute seinen ersten Absturz. Hier ist die Abfolge der Ereignisse:
Jul 22 05:00:22 kernel: BUG: kernel NULL pointer dereference, address: 0000000000000002kernel: Oops: 0000 [#1] PREEMPT SMP NOPTIkernel: CPU: 3 PID: 3235204 Comm: postmaster Not tainted 6.1.0-10-amd64 #1 Debian 6.1.37-1kernel: Voluntary context switch within RCU read-side critical section!kernel: CPU: 3 PID: 3235204 Comm: postmaster Tainted: G D 6.1.0-10-amd64 #1 Debian 6.1.37-1
journalctlzeigt den letzten Log-Eintrag um 06:40:50. Aber das Betriebssystem und Discourse liefen immer noch. Der letzte Eintrag war nur Standardgeplapper vom Dockerized Mail Agent, den ich auf derselben VM betreibe.- ~08:30 Uhr stellte ich fest, dass Discourse ein- und lauffähig war.
- 08:46 Uhr im Discourse-Fehlerprotokoll:
Unexpected error in Message Bus : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory - 08:53 Uhr im Discourse-Fehlerprotokoll:
Failed to process hijacked response correctly : ActiveRecord::ConnectionNotEstablished : connection to server on socket \"/var/run/postgresql/.s.PGSQL.5432\" failed: could not fork new process for connection: Cannot allocate memory - 09:01 Uhr im Discourse-Fehlerprotokoll:
Failed to handle exception in exception app middleware : ActiveRecord::StatementInvalid : PG::ObjectNotInPrerequisiteState: ERROR: lost connection to parallel worker - Letzter Beitrag auf Discourse um 09:17 Uhr.
- 09:22 Uhr im Discourse-Fehlerprotokoll:
'Track Visit' is still running after 90 seconds on db default, this process may need to be restarted! - 09:22 Uhr im Discourse-Fehlerprotokoll:
Redis::TimeoutError (Connection timed out) - Es gab weitere ähnliche Discourse-Protokolle bis zu dem Zeitpunkt, an dem ich bemerkte, dass die Website gegen 11:20 Uhr ausgefallen war.
Als ich mich nicht mehr per SSH anmelden konnte, machte ich diese Screenshots vom virtuellen Konsolenbetrachter und führte einen Hard-Reboot der VM durch:
Ich administriere seit langem Linux-Server, und diese Ereigniskette ergibt für mich keinen Sinn. Die Discourse-Protokolle scheinen ein ziemlich deutlicher Hinweis auf ein Out-of-Memory-Ereignis zu sein, und die virtuelle Konsole bestätigt, dass eine Komponente meines Dockerized Mail Servers auf derselben VM vom OOM-Killer eliminiert wurde. Aber es gibt keine Aufzeichnung dieser OOM-Aktion in journalctl, das anscheinend lange vor den anderen Systemausfällen aufgehört hat zu funktionieren. Das anscheinend erste Ereignis um 05:00:22 erwähnt mehrmals den postmaster-Prozess (von PostgreSQL im Discourse-App-Container), aber die Datenbank ist erst nach 09:17 Uhr komplett ausgefallen, als ein erfolgreicher Beitrag auf Discourse verzeichnet wurde.
Derzeit, nachdem das System den ganzen Tag gelaufen ist, zeigt es normale Speichernutzung, normalerweise liegt es ungefähr hier:
#> free -m
total used free shared buff/cache available
Mem: 7751 4965 129 1832 4773 2785
Swap: 3875 2879 996
Das einzig leicht Ungewöhnliche an meiner Konfiguration ist, dass der Swap-Speicher tatsächlich über Zram anstelle einer Swap-Datei oder Partition bereitgestellt wird. Ich benutze Zram seit Jahren und hatte nie Probleme. Außerdem habe ich die VM mit dem Debian-Installer-ISO neu installiert, um ein XFS-Root-Dateisystem anstelle des Standard-EXT4 zu haben, das die Debian-Images des Cloud-Anbieters verwenden. Der Host ist Hetzner, und nach meiner anfänglichen Clear Linux-Installation von Discourse habe ich eine andere VM für die Migration zu Debian erstellt, also bin ich vermutlich auf einem anderen Hypervisor-Knoten und glaube nicht, dass es ein Hardwareproblem ist. Daher frage ich mich, ob dies nur ein einfacher Out-of-Memory-Zustand war oder ob ich einen Grenzfall in der Kombination aus Kernel 6.1 + Zram + XFS + KVM/virtio gefunden habe? Ich würde mich über jede Einsicht freuen, die Sie haben.
. Versuchen Sie, sowohl Zram als auch XFS (eins nach dem anderen) zu entfernen und sehen Sie, was passiert. Mit Zram als meinem ersten Verdächtigen. Discourse sollte mit normalem Swap und ext4 problemlos laufen. Diese Optimierungen mögen Spaß machen, aber sie erhöhen derzeit die Komplexität Ihrer Installation. Sobald Ihre Instanz einwandfrei läuft, können Sie sie nacheinander wieder hinzufügen und sehen, wo die Dinge kaputt gehen.