Container chết đột ngột với exit code 137. Em chẩn đoán và khắc phục thế nào?

137 = 128 + 9, tức process bị SIGKILL.

Hai nguồn phổ biến: OOM killer của kernel (vượt memory limit) hoặc docker kill/hết grace period khi stop.
Phân biệt bằng cờ OOMKilled:

bash

docker inspect <id> --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
docker stats --no-stream          # live usage vs limit
dmesg -T | grep -i 'killed process'   # kernel OOM record on the host

Nguyên nhân hay gặp trong thực tế:

Runtime không thấy limit của cgroup. JVM cũ và một số cấu hình Node vẫn đọc RAM của host để tính heap → heap đặt lớn hơn limit container, chạm trần là bị kill. Java hiện đại có -XX:MaxRAMPercentage=75, Node dùng --max-old-space-size khớp limit.
Rò rỉ bộ nhớ thật — heap tăng đơn điệu; dựng heap snapshot/jmap để tìm.
Peak tạm thời: xử lý file lớn, đọc cả kết quả query vào bộ nhớ, thư viện ảnh. Cần stream thay vì buffer.
Limit đặt quá sát — không chừa chỗ cho page cache và overhead runtime.

Đặt limit tường minh để container không kéo cả host xuống, và luôn cấu hình runtime theo limit đó:

bash

docker run -m 512m --memory-swap 512m myapp

Ở Kubernetes, hiện tượng tương ứng là Pod OOMKilled với reason trong kubectl describe pod; giải pháp là chỉnh requests/limits cùng với tham số heap của runtime.

Xem toàn bộ Docker & Kubernetes cùng filter theo level & chủ đề con.

Mở danh sách Docker & Kubernetes

137 = 128 + 9, tức process bị SIGKILL.

Hai nguồn phổ biến: OOM killer của kernel (vượt memory limit) hoặc docker kill/hết grace period khi stop.
Phân biệt bằng cờ OOMKilled:

bash

docker inspect <id> --format '{{.State.OOMKilled}} {{.State.ExitCode}}'
docker stats --no-stream          # live usage vs limit
dmesg -T | grep -i 'killed process'   # kernel OOM record on the host

Nguyên nhân hay gặp trong thực tế:

Runtime không thấy limit của cgroup. JVM cũ và một số cấu hình Node vẫn đọc RAM của host để tính heap → heap đặt lớn hơn limit container, chạm trần là bị kill. Java hiện đại có -XX:MaxRAMPercentage=75, Node dùng --max-old-space-size khớp limit.
Rò rỉ bộ nhớ thật — heap tăng đơn điệu; dựng heap snapshot/jmap để tìm.
Peak tạm thời: xử lý file lớn, đọc cả kết quả query vào bộ nhớ, thư viện ảnh. Cần stream thay vì buffer.
Limit đặt quá sát — không chừa chỗ cho page cache và overhead runtime.

Đặt limit tường minh để container không kéo cả host xuống, và luôn cấu hình runtime theo limit đó:

bash

docker run -m 512m --memory-swap 512m myapp

Ở Kubernetes, hiện tượng tương ứng là Pod OOMKilled với reason trong kubectl describe pod; giải pháp là chỉnh requests/limits cùng với tham số heap của runtime.