- Verschifft
- 25. August 2026 um 19:39 UTC
- Autor
- Kamo
- Ausschuss
- c22edbb
Zwei Fehler, einer davon meiner. MINE FIRST: das mit dem Auto-Reconnect-Skript hinzugefügte "node --test"-Gate bei einer DIRECTORY, und der Läuferknoten löst ein nacktes Verzeichnis als Modul auf ausführen - MODULE_NOT_FOUND, Ausfahrt 1, Bereitstellung fehlgeschlagen. Beide schiebt hinterher (die bedingter Neustart-Fixierung und der kanarische Fehlalarm-Fixierung) daher nie versendet; Läufe 9150 und 9152 scheiterten und der Cluster blieb auf 3342ccd. Benennung des Tests Datei behebt es. Verifiziert mit dem genauen Befehl CI läuft, von der Repo-Wurzel. DAS OOM: "Ein Fehler ist aufgetreten" aus dem Nichts um 19:30 Uhr war eine OOMKill (Ausgang 137), kein Leck und nicht der Einsatz-Reanstart. "Jcmd VM.flags" auf der Live-Pod berichtet MaxHeapSize=32210157568 - eine 32 GB Haufendecke im Inneren einer 2 GiB Container. Dies ist Java 8 auf einem cgroup v2 host: seine Containererkennung nie liest /sys/fs/cgroup/memory.max (die Grenze ist dort sichtbar, 2147483648), also Größe sich gegen den Gastgeber 128 GB statt. Eden wuchs auf 1,0 GB und alte Gen auf 0,93 GB, während das Live-Set 23 MB war; ohne Druck zu sammeln, RSS stieg 821 MiB - 1963 MiB über vier Stunden und der Kern tötete es an der Grenze. Prometheus zeigt diese Kurve genau, und es begann VOR dem kanarischen existierte, so dass der Canary nicht involviert ist. -Xmx768m beseitigt die Abhängigkeit von der Containererkennung vollständig. MALLOC_ARENA_MAX und ActiveProcessorCount stoppen glibc und die GC von der Größe sich gegen die Die 48 CPUs des node. Das Limit wieder anzuheben war der falsche Schritt für sich: 1Gi-"2Gi hatte bereits versucht und nur geändert, wie lange es dauerte. Warnungen hinzugefügt, sowohl für den Ansatz (-85% des Grenzwerts) und der Veranstaltung (OOMKilled), weil das Gateway nicht abbauen, wenn es aus dem Gedächtnis läuft, es getötet wird, und jeder offene Desktop geht mit ihm.