- Spegnimento
- 16 agosto 2026 alle ore 01:13 UTC
- Autore
- Kamo
- Impegno
- 66cfbc5
Il contenitore ha funzionato con un limite 1Gi mentre l'immagine inizia il JVM con -XX: MaxRAMPercentage=70 -XX:+AlwaysPreTouch. Leggi il processo live, cioè MaxHeapSize=752877568 — 718Mi — e pre-touch significa memoria residente tracce il si alza come si impegna piuttosto che in ritardo dietro di esso. Non disponibile per questo servizio misure ~240Mi: metaspazio non recuperato, cache di codice, il thread STOMP/NATS/Tomcat pile e buffer diretti di MinIO. 718 più 240 è più di 1024, quindi il baccello non è mai stato dimensionato per lasciare il proprio mucchio raggiungere il soffitto con cui è stato configurato. Non aveva bisogno di una perdita o di una raffica. il traffico per morire; doveva essere utilizzato solo. Il kernel OOMKilled ogni poche ore — 959Mi di memoria anonima contro il tappo 1024Mi, riavviare il conteggio 2 in 18 ore — e ogni uccisione ha preso la cronologia delle chat, il websocket relay e ogni upload in volo con esso. 2Gi fa lo stesso 70% spaccato aggiungere: 1434Mi di mucchio più che ~240Mi è 1675Mi, circa 370Mi di headroom invece di un deficit 65Mi. Aumentare il limite è il leva destra piuttosto che abbassare MaxRAMPercentage — il 30% di 1Gi non è mai andato tenere un'applicazione Spring Boot con questi molti sottosistemi. Le richieste vanno 512Mi→1Gi così il programmatore viene detto la verità sul pavimento. Già applicato live con risorse kubectl set; questo è il cattura manifesto in modo che la prossima domanda CI non lo metta indietro.