- Spegnimento
- 25 agosto 2026 alle ore 19:39 UTC
- Autore
- Kamo
- Impegno
- c22edbb
Due difetti, uno dei miei. MINE FIRST: il cancello `node --test` aggiunto con lo script di ricollegamento automatico indicato in un DIRECTORY, e il nodo del corridore risolve una directory nuda come modulo per eseguire — MODULE NOT FOUND, uscita 1, schierare fallito. Entrambi spingono dopo di esso (il fix condizionale-restart e la correzione canarino falso-allarme) quindi mai spedito; corre 9150 e 9152 fallito e il gruppo rimase su 3342ccd. Denominazione del test il file lo risolve. Verificato con il comando esatto viene eseguito CI, dalla radice del repo. L'OOM: "un errore è avvenuto" dal nulla alle 19:30 era un OOMKill (uscita 137), non una perdita e non il riavvio di distribuzione. `jcmd VM.flags` sul pod live segnalato MaxHeapSize=32210157568 — un soffitto da 32 GB all'interno di un 2 GiB contenitore. Questo è Java 8 su un host cgroup v2: il suo rilevamento dei container mai legge /sys/fs/cgroup/memory.max (il limite è visibile lì, 2147483648), quindi si è dimensionato contro i 128 GB dell'ospite. Eden è cresciuto a ~1.0 GB e vecchio gen a ~0.93 GB mentre il set live era ~23 MB; senza alcuna pressione da raccogliere, RSS salito 821 MiB -> 1963 MiB oltre quattro ore e il kernel l'ha ucciso al limite. Prometeo mostra esattamente quella curva, e ha cominciato BEFORE il canario esisteva, quindi il canarino non è implicato. -Xmx768m rimuove completamente la dipendenza dal rilevamento del contenitore. MALLOC ARENA MAX e ActiveProcessorCount stop glibc e il GC da setacciarsi contro Node ha 48 CPU. Aumentare di nuovo il limite è stata la mossa sbagliata da solo: 1Gi->2Gi era già stato provato e cambiato solo quanto tempo ci voleva. Avvisi aggiunti sia per l'approccio (>85% del limite) che per l'evento (OOOMKilled), perché il gateway non si degrada quando esaurisce la memoria — è ucciso, e ogni desktop aperto va con esso.