pprof cho biết cấp phát ở hàm nào, dòng nào. Nhưng có hai góc nhìn khác hẳn: đo thật cùng một chương trình, inuse_space chỉ hàm giữ 47MB RAM còn alloc_space chỉ hàm churn 515MB — hai thủ phạm hoàn toàn khác. Chọn sai chỉ số là đuổi nhầm. Go 1.23.
Benchmark cho biết chậm, nhưng không cho biết khóa nào nghẽn. Mutex profile đo tổng thời gian goroutine phải chờ khóa. Đo thật: 10 goroutine tranh một mutex nóng tích lũy 20,8 giây chờ, 100% quy về đúng khóa đó, khóa nguội bị loại. Cách bật, phân tích, và sửa. Go 1.23.
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.
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.
Tracing chỉ ra chặng nào chậm; nhưng trong một chặng, HÀM nào ngốn CPU hay giữ RAM? Đừng đoán — pprof của Go đo trực tiếp. Bài này chạy thật runtime/pprof: CPU profile chỉ ra main.hotHash chiếm 100% CPU (qua sha256), heap profile chỉ ra main.allocBig giữ đúng 197.76MB còn allocSmall biến mất vì đã bị GC. Kèm cách đọc hai cột flat vs cum mà nhiều người nhầm.