json.Unmarshal cần toàn bộ dữ liệu trong RAM rồi dựng mọi struct cùng lúc — bộ nhớ tỉ lệ với kích thước tệp, tệp GB làm sập app. json.Decoder đọc lười từng phần tử, giữ bộ nhớ hằng số. Đo thật trong Go: xử lý tệp JSON 41.6 MB, Unmarshal tốn +142.5 MB heap, streaming chỉ +2.3 MB — cùng kết quả.
Bloom filter là cấu trúc xác suất trả lời phần tử có thể có trong tập hay chắc chắn không — chỉ bằng một mảng bit và k hàm băm, không lưu phần tử. Đo thật khi tự cài trong Go: 1 triệu phần tử, 0 âm tính giả, dương tính giả đúng 1% như thiết kế, và bộ nhớ 1.20 MB so với 56.1 MB của set thường.
namespace cô lập tầm nhìn; cgroup là nửa còn lại — giới hạn tài nguyên. Bài này chạy thật: --cpus 0.25 làm cùng workload chậm đúng 4 lần, giới hạn nằm trong file /sys/fs/cgroup (memory.max, cpu.max), và container vượt --memory 32m bị kernel OOM kill thật (OOMKilled=true, exit 137). Hai kiểu vượt khác nhau: RAM bị giết, CPU chỉ throttle.
Thấy VSZ của app là 2GB và hoảng? Đừng vội. VSZ là không gian địa chỉ ẢO đặt chỗ, còn RSS mới là RAM vật lý thật. Bài này chạy thật: mmap 500MB làm VSZ nhảy lên 513MB nhưng RSS vẫn 7MB (chưa chạm), rồi RSS tăng dần khi chạm vào — cấp phát lười. Đọc đúng cột trong ps/proc để không lo hão.
Máy chậm hoặc nóng — tiến trình nào là thủ phạm? ps aux --sort xếp hạng ngay: sort theo %cpu tìm kẻ busy loop, sort theo %mem tìm kẻ ngốn RAM. Bài này chạy thật hai tiến trình (một ngốn CPU 99.5%, một giữ 257MB RAM) và tìm chúng; giải thích vì sao %CPU có thể vượt 100% trên đa lõi, và đọc đúng cột RSS.
Redis sống trong RAM có hạn — hai cơ chế quyết định số phận key: TTL (tự hết hạn) và eviction (đẩy key ra khi đầy). Bài này đo thật trong redis-lab: key đặt PX 150ms tự biến mất sau đó (GET trả nil); và với maxmemory 3mb, nạp 100.000 key — chính sách allkeys-lru đẩy 89.992 key để ghi vẫn thành công (bộ nhớ giữ đúng 3.00M), còn noeviction từ chối ghi với lỗi OOM. Chọn chính sách theo vai trò Redis.