"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.
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.
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.
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.
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.
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.