Cà Phê & Code — Hệ thống

Rò rỉ file descriptor: vì sao app chạy tốt vài giờ rồi chết vì "Too many open files"

Tue, 22 Sep 2026 00:00:00 +0700

App chạy ổn lúc đầu rồi bỗng crash sau vài giờ với 'Too many open files'? Gần như luôn là rò rỉ file descriptor — mở file/socket mà quên đóng. Bài này chạy thật: mô phỏng rò rỉ đến khi chạm ulimit và nhận Errno 24, so với bản dùng with (fd phẳng lì ở 4), và cách đếm fd qua /proc/pid/fd để phát hiện sớm.

strace: nhìn thấy chương trình thật sự nói gì với kernel — khi log im lặng

Tue, 22 Sep 2026 00:00:00 +0700

App chạy lỗi mà log không nói gì? strace cho bạn thấy MỌI syscall chương trình gọi — mở file nào, đọc bao nhiêu byte, kết nối đi đâu. Bài này chạy thật: strace cat phơi bày openat/read/write, bắt file thiếu qua ENOENT, lọc chỉ syscall mạng, và gắn vào tiến trình đang chạy — công cụ debug mạnh nhất khi bạn không có mã nguồn hay log.

/proc/: cửa sổ nhìn vào tiến trình đang sống — không cần dừng hay strace

Tue, 22 Sep 2026 00:00:00 +0700

Muốn biết một tiến trình đang mở file nào, dùng bao nhiêu RAM thật, chạy từ binary nào — mà không làm nó chậm đi? Đọc /proc/. Bài này chạy thật: cmdline cho lệnh đầy đủ, status cho VmRSS (RAM thật), fd/ cho file descriptor đang mở, cwd/exe cho thư mục và binary, maps cho bản đồ bộ nhớ — hệ thống file ảo do kernel sinh ra.

RSS vs VSZ: vì sao "app dùng 2GB bộ nhớ" thường không phải 2GB RAM thật

Tue, 22 Sep 2026 00:00:00 +0700

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.

real, user, sys: ba con số của time cho biết chương trình chậm do CPU hay do chờ

Tue, 22 Sep 2026 00:00:00 +0700

Chương trình chậm — nhưng chậm vì tính toán nặng, vì chờ I/O, hay vì gọi kernel quá nhiều? Ba con số của time trả lời ngay. Bài này đo thật: chương trình CPU-bound cho user≈real, sleep-bound cho real≫user+sys (đang chờ), syscall-heavy cho sys cao — cùng 'chậm' nhưng ba nguyên nhân và ba cách sửa khác nhau.

Tín hiệu để debug: bắt chương trình treo tự khai nó đang kẹt ở đâu

Tue, 22 Sep 2026 00:00:00 +0700

App treo, không log, không phản hồi — làm sao biết nó kẹt ở đâu? Nhiều runtime có 'cửa hậu' qua tín hiệu để tự in trạng thái. Bài này chạy thật: gửi SIGQUIT cho một chương trình Go bị treo, runtime in stack tất cả goroutine và chỉ đúng dòng code đang kẹt (chan receive ở hang.go:12); và SIGSEGV/panic tự in nơi crash.

strace -c và -T: tìm chính xác syscall nào khiến chương trình chậm

Tue, 22 Sep 2026 00:00:00 +0700

"App chậm mà không biết chậm ở đâu" — strace -c cho bảng tóm tắt: syscall nào chiếm bao nhiêu phần trăm thời gian và gọi bao nhiêu lần. Bài này đo thật: một chương trình ghi 20000 lần 1 byte cho thấy write chiếm 98% thời gian với 20000 lần gọi; gom lại còn 1 lần. Cùng -T đo thời gian từng syscall để soi cái chậm bất thường.

Tìm tiến trình ngốn CPU hay RAM: ps và top, và vì sao %CPU có thể vượt 100%

Tue, 22 Sep 2026 00:00:00 +0700

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.

Theo dõi I/O của tiến trình: /proc//io và bẫy page cache đánh lừa bạn

Tue, 22 Sep 2026 00:00:00 +0700

Máy chậm mà CPU vẫn rảnh? Có thể một tiến trình đang quật đĩa. /proc//io cho biết nó đọc/ghi bao nhiêu byte. Bài này chạy thật: một tiến trình ghi 200MB hiện write_bytes=200MB; nhưng đọc file trong page cache cho rchar=100MB mà read_bytes=0 — dữ liệu từ RAM, không chạm đĩa. Biết đọc cột nào để không bị đánh lừa.

Latency và percentile p99: vì sao "trung bình 0.1ms" vẫn có khách phải chờ 6ms

Tue, 22 Sep 2026 00:00:00 +0700

Báo cáo 'latency trung bình 0.133ms' nghe tuyệt — nhưng nó nói dối về trải nghiệm thật. Bài này đo thật 100.000 thao tác: p50 chỉ 0.003ms, mà p99 lên tới 6.121ms — mean giấu đuôi 46 lần, và 98% request thực ra nhanh hơn cả con số trung bình. Cách tính p50/p95/p99 bằng sort + nearest-rank, và vì sao SLO phải dùng percentile chứ không phải mean.

Load average thực sự nghĩa là gì: ba số 1/5/15 phút, và vì sao load cao không phải lúc nào cũng là CPU

Tue, 22 Sep 2026 00:00:00 +0700

Ai cũng thấy 'load average: 3.54, 1.34, 0.49' mà ít người đọc đúng. Nó không phải %CPU — mà là số tiến trình trung bình đang chạy HOẶC chờ I/O. Bài này chạy thật: 4 tiến trình CPU-bound làm load 1-phút leo từ 0.11 lên ~4; rồi 6 tiến trình dd kẹt ở D-state (chờ đĩa, gần 0% CPU) vẫn đẩy load lên — chứng minh load khác CPU. Và cách so load với số core để biết máy có quá tải không.

Profiling CPU: tìm đúng hàm nóng (và đúng dòng) thay vì tối ưu theo cảm giác

Tue, 22 Sep 2026 00:00:00 +0700

Bạn đoán hàm A chậm, tối ưu cả ngày, hóa ra thủ phạm là hàm B. Profiler chấm dứt việc đoán mò: nó lấy mẫu stack định kỳ và chỉ ra hàm nào thực sự ngốn CPU bằng số. Bài này thử perf thật (bị container chặn — báo trung thực) rồi dùng Go pprof: hàm nóng chiếm 75.79% CPU, và pprof -list chỉ đúng dòng 17 ngốn 710ms. Bài cuối loạt Debug, kèm tổng kết 12 phần.