Neu
- Bringt das Holen eines Repositories einen neuen Commit, startet Kastra die Anwendung der Domain danach selbst neu: eine Node.js-Anwendung wird deployt (Abhängigkeiten, Bau, Neustart), ein laufender Container samt Bau neu gestartet. Ein angehaltener Container bleibt angehalten. Der Schalter Anwendung nach einem neuen Stand neu starten am Repository ist für neue und vorhandene Repositories eingeschaltet.
- Beendet der Kernel einen Prozess, weil der Arbeitsspeicher nicht reicht, meldet Kastra das als neue Alarmart
OOM_KILL— mit dem Namen des Prozesses und den Zeilen des Kernels. Kritisch, wenn der ganze Node voll war; eine Warnung, wenn nur eine Subscription an die Speichergrenze ihres Tarifs gestoßen ist. Bisher fiel ein solcher Abbruch niemandem auf. - Die Übersicht eines Nodes zeigt unter Fakten, wie viel Swap er hat, und weist darauf hin, wenn er keinen hat.
Geändert
- Die Control Plane nimmt sich höchstens 1,5 GB Heap statt bis zu 70 % des Arbeitsspeichers. Auf einem Host, den sie mit Datenbanken und Kundenanwendungen teilt, durfte sie sich bisher fast alles nehmen. Reicht der Heap nicht, beendet sie sich und wird neu gestartet, statt halb lebendig weiterzulaufen. Eine andere Grenze steht als
KASTRA_JAVA_OPTSin/etc/kastra/control-plane.env.
Eingriffe am Node
- W-003-swapdatei — legt auf einem Node ohne Swap die Swapdatei
/kastra.swapan (ein Viertel des Arbeitsspeichers, mindestens 1 GiB, höchstens 4 GiB), trägt sie in/etc/fstabein und setzt über/etc/sysctl.d/90-kastra-swap.confvm.swappiness = 10. Ein Node, der schon Swap hat, in einem Container läuft, nicht auf ext4 oder xfs liegt oder weniger als das Vierfache der Dateigröße frei hat, bleibt unverändert; die Ausgabe sagt, warum. Läuft je Node einmal, auf einem neu installierten Node gleich bei der Installation. Zurücknehmbar:swapoff /kastra.swap, die Zeile aus/etc/fstabnehmen,/kastra.swapund/etc/sysctl.d/90-kastra-swap.conflöschen.