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.
Go có bộ thu gom rác nhưng vẫn rò bộ nhớ được — vì GC chỉ dọn thứ không ai giữ. Đo thật một rò goroutine: NumGoroutine tăng 1001 lên 5001, HeapInuse tăng 63 lên 316 MB đều đặn dù GC chạy mỗi vòng. Bốn mẫu rò kinh điển và ba cách phát hiện. 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.
Goroutine kẹt vĩnh viễn (chờ channel không ai gửi) không thoát và GC không dọn được — mỗi request rò một cái, số goroutine tăng mãi tới khi hết RAM. Đo thật trong Go: 1000 request rò 1000 goroutine (NumGoroutine 1→1001 không giảm), và pprof goroutine chỉ đúng chỗ kẹt tại một dòng code.
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.