Debug và hiệu năng Linux: soi chương trình đang chạy

1 strace: nhìn thấy chương trình thật sự nói gì với kernel — khi log im lặng 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. 22/09/2026 · 5 phút đọc

2 strace -c và -T: tìm chính xác syscall nào khiến chương trình chậm "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. 22/09/2026 · 6 phút đọc

3 /proc/<pid>: cửa sổ nhìn vào tiến trình đang sống — không cần dừng hay strace 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/<pid>. 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. 22/09/2026 · 5 phút đọc

4 Rò rỉ file descriptor: vì sao app chạy tốt vài giờ rồi chết vì "Too many open files" 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. 22/09/2026 · 5 phút đọc

5 RSS vs VSZ: vì sao "app dùng 2GB bộ nhớ" thường không phải 2GB RAM thật 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. 22/09/2026 · 5 phút đọc

6 real, user, sys: ba con số của time cho biết chương trình chậm do CPU hay do chờ 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. 22/09/2026 · 5 phút đọc

7 Tín hiệu để debug: bắt chương trình treo tự khai nó đang kẹt ở đâu 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. 22/09/2026 · 6 phút đọc

8 Tìm tiến trình ngốn CPU hay RAM: ps và top, và vì sao %CPU có thể vượt 100% 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. 22/09/2026 · 5 phút đọc

9 Theo dõi I/O của tiến trình: /proc/<pid>/io và bẫy page cache đánh lừa bạn Máy chậm mà CPU vẫn rảnh? Có thể một tiến trình đang quật đĩa. /proc/<pid>/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. 22/09/2026 · 5 phút đọc

10 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 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. 22/09/2026 · 7 phút đọc

11 Latency và percentile p99: vì sao "trung bình 0.1ms" vẫn có khách phải chờ 6ms 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. 22/09/2026 · 6 phút đọc

12 Profiling CPU: tìm đúng hàm nóng (và đúng dòng) thay vì tối ưu theo cảm giác 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. 22/09/2026 · 7 phút đọc