Benchmark cục bộ chỉ đo cái bạn nghĩ là nóng; điểm nóng production thường ở chỗ bất ngờ với tải và dữ liệu thật. net/http/pprof phơi endpoint để thu hồ sơ từ dịch vụ đang chạy mà không dừng nó. Đo thật trong Go: thu CPU profile 3 giây từ service live, pprof chỉ đúng hàm nóng 100% CPU.
"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.
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.
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.
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á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.