Hệ điều hành · 19/09/2026

Linux dùng nhiều RAM và OOM Killer: Cách chẩn đoán, xử lý an toàn

Linux hiển thị RAM “used” cao chưa chắc là thiếu bộ nhớ. Kernel chủ động dùng RAM trống cho page cache và có thể thu hồi khi ứng dụng cần. Sự cố thật sự xuất hiện khi MemAvailable giảm kéo dài, swap hoạt động mạnh, tiến trình bị stall hoặc kernel phải dùng OOM Killer để giải phóng bộ nhớ.

Linux hiển thị RAM “used” cao chưa chắc là thiếu bộ nhớ. Kernel chủ động dùng RAM trống cho page cache và có thể thu hồi khi ứng dụng cần. Sự cố thật sự xuất hiện khi MemAvailable giảm kéo dài, swap hoạt động mạnh, tiến trình bị stall hoặc kernel phải dùng OOM Killer để giải phóng bộ nhớ.

Hiểu đúng used, free và available

free -h
cat /proc/meminfo | head -20

Trong free, hãy nhìn cột available trước cột free. MemAvailable là ước tính lượng bộ nhớ có thể cấp cho ứng dụng mới mà không cần swap, có tính tới phần page cache và slab có thể thu hồi. Cache lớn thường là tín hiệu Linux tận dụng RAM hiệu quả, không phải memory leak.

Cảnh báo đáng quan tâm là available liên tục đi xuống, swap-in/swap-out tăng, latency xấu và workload bị kill. Một snapshot đơn lẻ không đủ; cần chuỗi số liệu theo thời gian.

1. Xác nhận memory pressure

free -h
vmstat 1 10
cat /proc/pressure/memory
swapon --show

Trong vmstat, si và so cho biết swap-in/swap-out. Một ít swap đã dùng không đồng nghĩa đang thiếu RAM; hoạt động swap liên tục cùng latency cao mới đáng lo. PSI tại /proc/pressure/memory đo tỷ lệ thời gian task bị chặn do tranh chấp memory. Dòng full tăng kéo dài cho thấy toàn bộ workload không nhàn rỗi bị stall và hệ thống có nguy cơ thrashing/OOM.

2. Tìm process sử dụng bộ nhớ

ps -eo pid,ppid,user,comm,rss,vsz,%mem --sort=-rss | head -20
top
systemd-cgtop

RSS là phần memory resident của process, nhưng cộng RSS của nhiều process có thể đếm trùng shared memory. VSZ bao gồm không gian địa chỉ đã map và không đồng nghĩa RAM vật lý. Với process nghi vấn, xem chi tiết:

cat /proc/PID/status
cat /proc/PID/smaps_rollup
pmap -x PID | tail -1

smaps_rollup giúp phân biệt private, shared, anonymous và file-backed memory. Trong container/systemd, kiểm tra cả cgroup vì OOM có thể xảy ra bên trong limit dù host còn RAM.

3. Phân biệt tải cao, cache và memory leak

Tải hợp lệ: memory tăng theo traffic rồi giảm khi tải hạ hoặc worker được recycle.
Page cache: Cached cao nhưng MemAvailable vẫn tốt; kernel thu hồi khi cần.
Memory leak: private/anonymous RSS của cùng process tăng dần qua nhiều chu kỳ tải và không trở lại baseline.
Unbounded queue: backlog tăng làm process giữ ngày càng nhiều object; sửa throughput và backpressure.
tmpfs/shmem: dữ liệu trong /dev/shm hoặc tmpfs tiêu thụ RAM dù nhìn giống file.
Kernel/slab: process RSS không giải thích được tổng memory; kiểm tra Slab, SReclaimable và subsystem liên quan.

Ghi RSS, request rate, queue depth và thời điểm deploy trên cùng biểu đồ. Tương quan theo thời gian hữu ích hơn việc restart rồi mất bằng chứng.

4. Xác nhận OOM Killer đã hoạt động

journalctl -k -g 'Out of memory|Killed process|oom-kill' --since today
dmesg -T | grep -Ei 'out of memory|killed process|oom-kill'
journalctl -u systemd-oomd --since today
oomctl

Kernel OOM Killer chọn task dựa trên heuristic, mức memory/swap và oom_score_adj. systemd-oomd là cơ chế userspace có thể hành động sớm dựa trên cgroup và memory pressure. Đọc log để biết global OOM hay cgroup OOM, process nào bị kill, mức memory và constraint liên quan.

Không kết luận process bị kill là thủ phạm duy nhất. Nó có thể chỉ là nạn nhân được chọn trong khi nguyên nhân là traffic tăng, limit sai, nhiều worker, leak ở dịch vụ khác hoặc host overcommit.

5. Ổn định hệ thống đang gặp sự cố

Dừng hoặc giảm nguồn traffic/job không quan trọng.
Chụp số liệu free, vmstat, process, cgroup và OOM log.
Scale workload sang node khác hoặc giảm concurrency có kiểm soát.
Restart đúng service rò bộ nhớ nếu cần phục hồi tức thời.
Thêm swap tạm thời chỉ khi hiểu rủi ro latency và storage.
Giám sát sau thay đổi, không coi restart là sửa tận gốc.

Tránh chạy echo 3 > /proc/sys/vm/drop_caches như biện pháp chữa RAM. Xóa cache có thể làm I/O và latency xấu hơn; kernel vốn sẽ thu hồi cache khi cần.

6. Swap: vùng đệm, không phải RAM miễn phí

Swap có thể tạo thời gian phản ứng trước burst và đẩy page ít dùng ra khỏi RAM, nhưng storage chậm hơn RAM nhiều lần. Không có swap làm biên an toàn mỏng hơn; swap quá lớn không sửa được leak vô hạn.

swapon --show
cat /proc/sys/vm/swappiness
vmstat 1

Điều chỉnh vm.swappiness chỉ sau khi đo workload. Giá trị thấp không có nghĩa kernel tuyệt đối không swap. Với database, latency-sensitive service và Kubernetes, cần tuân theo hướng dẫn cụ thể của workload/orchestrator.

7. Đặt giới hạn và headroom

Với systemd service, có thể đặt giới hạn cgroup trong unit:

[Service]
MemoryHigh=1500M
MemoryMax=2G
OOMPolicy=stop

MemoryHigh tạo pressure/throttling mềm; MemoryMax là trần cứng. Chọn mức từ dữ liệu peak hợp lệ, không tùy ý. Sau khi sửa unit:

sudo systemctl daemon-reload
sudo systemctl restart example.service
systemctl show example.service -p MemoryCurrent -p MemoryPeak -p MemoryHigh -p MemoryMax

Trong container, memory limit phải bao gồm heap, native allocation, page cache và sidecar. Giữ headroom cho kernel, SSH, monitoring và daemon nền; không phân bổ 100% RAM host cho workload.

8. Điều chỉnh ứng dụng thay vì chỉ tăng RAM

Giới hạn worker/concurrency theo peak memory mỗi worker.
Dùng streaming/chunking thay vì nạp toàn bộ file hoặc query result.
Đặt giới hạn queue, timeout, payload và upload.
Cấu hình cache eviction và maximum memory.
Recycle worker sau số request hợp lý như biện pháp giảm rủi ro, không che leak mãi mãi.
Profile heap/native memory trong môi trường gần production.

Tăng RAM hợp lý khi working set thật sự tăng; nếu đường memory vẫn tăng không giới hạn, RAM thêm chỉ trì hoãn OOM.

9. Giám sát và cảnh báo sớm

Theo dõi MemAvailable, working set theo cgroup, swap I/O, PSI memory, OOM events, restart count và queue depth. Cảnh báo dựa trên thời gian kéo dài và áp lực, không chỉ phần trăm RAM used.

Lưu metric sau deploy đủ lâu để nhận ra leak chậm. Alert nên dẫn tới runbook có lệnh thu thập bằng chứng, owner dịch vụ và điều kiện scale/restart rõ ràng.

Sai lầm thường gặp

Thấy RAM used cao và kết luận leak mà không xem available/cache.
Cộng RSS mọi process và coi đó là tổng RAM chính xác.
Restart ngay trước khi lưu log và biểu đồ.
Tắt OOM Killer hoặc đặt oom_score_adj=-1000 tràn lan.
Dùng drop_caches định kỳ như công cụ tối ưu.
Chỉ tăng swap/RAM trong khi queue hoặc concurrency không giới hạn.
Chỉ theo dõi host, bỏ qua cgroup/container OOM.

Checklist xử lý

Xác nhận MemAvailable, swap activity và PSI theo thời gian.
Xác định process/cgroup và loại memory đang tăng.
Đọc kernel log và systemd-oomd log để phân loại OOM.
Lưu bằng chứng trước khi restart hoặc kill.
Giảm tải và khôi phục dịch vụ theo ưu tiên.
Sửa leak, concurrency, queue hoặc cache policy.
Đặt MemoryHigh/MemoryMax và headroom phù hợp.
Load test và tạo cảnh báo trước ngưỡng OOM.

Kết luận

Điều tra memory trên Linux bắt đầu từ pressure và khả năng thu hồi, không phải màu đỏ trong cột used. Hãy kết hợp MemAvailable, PSI, swap I/O, process/cgroup metrics và OOM log để tìm nguyên nhân. Restart có thể cứu dịch vụ, nhưng giới hạn hợp lý, backpressure và sửa ứng dụng mới ngăn sự cố quay lại.