- Spegnimento
- 16 agosto 2026 alle ore 01:43 UTC
- Autore
- Kamo
- Impegno
- 4fd9a2a
Niente stava guardando la memoria. MediaService è stato OOMKilled ogni poche ore per la maggior parte di un giorno e EmailService sei volte, e il modo in cui chiunque ha scoperto era una chat finestra che aveva tranquillamente smesso di caricare messaggi — un contenitore che muore e riavviarsi all'interno di un secondo legge come una funzione rotta, non come un'interruzione. Tre regole. ContainerOOMKilled fuochi sull'evento; ContainerOOMKillLoop separa un one-off da un pod che viene ucciso ripetutamente, che riavvia veloce abbastanza per mostrare ancora 1/1 Corsa. ContainerMemoryNearLimit è quello che sarebbe hanno preso in anticipo questi giorni: > 85% del limite tenuto per 30 minuti. Per un JVM su MaxRAMPercentage che non è un pod occupato, è un baccello seduto al suo soffitto di mucchio con non-sapone impilato in cima, che è lo stato costante immediatamente prima kernel interviene. Un quarto, informativo, bandiere contenitori senza limiti tutti — non possono essere OOMKilled dal proprio gruppo, ma possono prendere un nodo giù. Verificato contro dati reali piuttosto che assunti: le espressioni sono state valutate su questo cluster, e querying le ultime 12 ore mostra il motivo="OOMKilled" serie per esattamente kamowsemail (18:33-01:28 UTC) e kamowsmedia (21:28-01:03 UTC) — i due baccelli che stavano fallendo. Le regole avrebbero sparato critica su entrambi. Un avviso che silenziosamente non corrisponde nulla è lo stesso fallimento di nessun avviso, in modo che il controllo contava più del YAML. Applicato a mano; il monitoraggio/ non è un obiettivo di applicazione CI.