“Heap ổn mà pod OOMKill.” Dashboard GC xanh; K8s vẫn bắn. Bạn đang nhìn sai lớp số.
Nền: VSS / RSS / USS, GC. Bài này: heap process vs RSS vs cgroup memory limit.
Ba con số
Heap (V8/JVM…)
Object do runtime quản, GC dọn
process.memoryUsage().heapUsed · jvm heap
RSS
RAM process (heap + native + stack + mapped…)
“To hơn heap” là bình thường
cgroup memory max (container)
Trần K8s/Docker — vượt → OOMKill
Kernel không hỏi “heap graph có đẹp không”Bẫy thường
- Heap phẳng, RSS tăng: Buffer/native, off-heap, memory leak C++, page cache mapped file…
- Limit container 512Mi, RSS steady 480Mi + spike → kill.
- Unbounded in-flight nâng cả heap và RSS trước khi GC kip.
- GC “working” nhưng allocation rate > collect + limit chặt.
Log / event điển hình (K8s)
Memory cgroup out of memory: Killed process ...
(container memory limit)
// khác node pressure — pod có thể bị evict với reason khác
So: kubectl top / metrics RSS ≈ limit?
heapUsed từ runtime có còn “thoáng”?Debug OOM checklist
- OOMKill message: container limit hay node pressure?
- RSS vs limit ngay trước kill.
- Heap used vs RSS gap → native/off-heap?
- In-flight / cache size / buffer pool metrics.
- Reproduce với bound inventory xem RSS có hạ không.
Một câu
OOM là chuyện limit + RSS (và native), không chỉ “heap graph
đẹp”.
Nhìn đúng lớp số trước khi tăng heap flag mù.