- Ya
- 16 Agosti 2026, 01:13 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 66cfbc5
The container ran with a 1Gi limit while the image starts the JVM with -XX:MaxRAMPercentage=70 -XX:+AlwaysPreTouch. Read off the live process, that is MaxHeapSize=752877568 — 718Mi — and pre-touch means resident memory tracks the heap up as it commits rather than lagging behind it. Non-heap for this service measures ~240Mi: uncapped metaspace, code cache, the STOMP/NATS/Tomcat thread stacks and MinIO's direct buffers. 718 plus 240 is more than 1024, so the pod was never sized to let its own heap reach the ceiling it was configured with. It did not need a leak or a burst of traffic to die; it only had to be used. The kernel OOMKilled it every few hours — 959Mi of anonymous memory against the 1024Mi cap, restart count 2 in 18 hours — and each kill took chat history, the websocket relay and every upload in flight with it. 2Gi makes the same 70% split add up: 1434Mi of heap plus that ~240Mi is 1675Mi, around 370Mi of headroom instead of a 65Mi deficit. Raising the limit is the right lever rather than lowering MaxRAMPercentage — 30% of 1Gi was never going to hold a Spring Boot application with this many subsystems. Requests go 512Mi→1Gi so the scheduler is told the truth about the floor. Already applied live with kubectl set resources; this is the manifest catching up so the next CI apply does not put it back.