- Shipped
- 16. August 2026 um 01:13 UTC
- Author
- Kamo
- Commit
- 66cfbc5
Der Container lief mit einem 1Gi-Limit, während das Bild die JVM mit startet -XX:MaxRAMPercentage=70 -XX:+AlwaysPreTouch. Lesen Sie den Live-Prozess, das ist MaxHeapSize=752877568 - 718Mi und Pre-Touch bedeutet, dass Resident Memory Tracks häufen, wie es sich bekennt, anstatt hinterherzuhinken. Non-Haufen für diesen Service misst ca. 240Mi: ungedeckelter Metaspace, Code-Cache, der STOMP/NATS/Tomcat-Thread Stapel und die direkten Puffer von MinIO. 718 plus 240 ist mehr als 1024, so dass die Hülse nie so groß war, dass sie ihren eigenen Haufen vermietet die Decke erreichen, mit der es konfiguriert wurde. Es brauchte kein Leck oder einen Ausbruch von Verkehr zum Sterben; es musste nur benutzt werden. Der Kernel OOMKilled es alle paar Stunden 959Mi anonymen Speicher gegen die 1024Mi Kappe, Neustart-Zählung 2 in 18 Stunden - und jeder Kill nahm Chat-Verlauf, die Websocket-Relais und jeden Upload in Flug mit ihm. 2Gi macht die gleichen 70% Split addieren: 1434Mi Haufen plus, dass 240Mi ist 1675Mi, rund 370Mi Kopffreiheit statt eines 65Mi Defizit. Die Anhebung des Limits ist die rechter Hebel statt Senkung der MaxRAMProcentage - 30% von 1Gi ging nie um eine Spring Boot-Anwendung mit so vielen Subsystemen zu halten. Anfragen gehen 512Mi-1Gi, so dass der Zeitplaner die Wahrheit über den Boden gesagt wird. Bereits angewendet live mit kubectl gesetzt Ressourcen; dies ist die manifeste fangen up, so dass die nächste CI gelten nicht setzen es zurück.