Problem

feature-host is swapping and sluggish; latency alarms are firing and the OOM killer is about to start reaping. Something is eating the RAM. Find the single process responsible, prove it's a real per-process leak (not just page cache, and not the process with the scary-big virtual size), and name the fix.

Initial setup

• Host: feature-host, Debian 12, ~1.5 GiB RAM, 2 vCPU, swap configured.
• A feature-store service, a JVM gateway, plus the usual system procs.

Acceptance

You've solved it when:

• free shows available near zero AND buff/cache is small too — so

the low memory is NOT reclaimable page cache (the classic misread).

• top/ps (sorted by memory) show ONE process dominating RES/%MEM

(the feature-store, PID 622, ~64% MEM). You've ruled out the gateway JVM — its VIRT is huge but its RES is small (virtual ≠ resident).

• You've named the fix: restart the leaker for immediate relief, then stop

the leak in the app (bound the cache / fix the allocation) or swap the allocator — NOT "just add swap", NOT a reboot that hides the slope, and NOT blaming buff/cache.