Pprof

🇬🇧 Read the English version on tanhdev.com ← Chương trước: Băm Nhất Quán (Consistent Hashing) — Node Ảo, Phương Sai Tải & Vòng CRC32 Trong Go | Mục lục Series | Chương tiếp theo: Bảo Mật & Giới Hạn Tốc Độ API (Rate Limiting) — Token Bucket, Leaky Bucket & Redis Lua → Answer-first: Khả năng quan sát (Observability) và profiling trong Go sử dụng các endpoint runtime/pprof chuyên sâu. So sánh Heap Profile diff định vị chính xác rò rỉ bộ nhớ (memory leaks), bắt bệnh rò rỉ goroutine qua stack dump, và phân tích Flame Graph giúp tối ưu hóa điểm nghẽn CPU trên Production với overhead tối thiểu. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Profiling Go trong production với pprof cho phép chẩn đoán chính xác CPU hotspots, phân biệt cấp phát bộ nhớ (alloc_space vs inuse_space) và định vị goroutine leaks với overhead dưới 2%. Bật endpoint trên port nội bộ cô lập, dùng kubectl port-forward và custom pprof labels để phân tích đa chiều. Yêu cầu tiên quyết: Hướng dẫn này đề cập đến việc profile và chẩn đoán các sự cố hiệu năng phức tạp trên production. Nếu bạn đang xử lý tình trạng số lượng goroutine tăng trưởng không kiểm soát, hãy chắc chắn rằng bạn đã hiểu các khái niệm nền tảng trong bài viết Phát hiện và Xử lý Goroutine Leak trên Production Go Services. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Remote profiling Go trong Kubernetes được thực hiện an toàn qua 3 mô hình: tạo tunnel tức thời bằng kubectl port-forward trên cổng admin cô lập, gắn container sidecar cho cụm tăng cường bảo mật, hoặc tích hợp Pyroscope continuous profiling (1–3% CPU). Phân tích flame graph phát hiện hot-path và tối ưu GC latency. Bạn đã gắn các bộ thu thập đo lường cho service Go của mình với net/http/pprof, chạy thử lệnh go tool pprof cục bộ (local) kiểm tra file binary lúc dev, và đã nhìn rõ mồn một các “hot path” (đường nghẽn cổ chai tốn thời gian nhất) trên biểu đồ ngọn lửa (flame graph). Thế rồi bạn triển khai lên Kubernetes và các điểm nghẽn ấy biến mất hoàn toàn — bởi vì hồ sơ tải (workload profile) trong Kubernetes khác xa với việc test cục bộ (mix request khác nhau, áp lực pool kết nối khác nhau, hành vi GC cũng khác dưới mức chịu tải thực tế, và cả sự can thiệp từ bộ lập lịch (scheduler) của các pod nằm chung node). ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Rò rỉ Goroutine xảy ra khi goroutine bị block vĩnh viễn trên unbuffered channel, context thiếu hủy, hoặc HTTP body chưa đóng, dẫn đến giữ heap memory và gây sự cố Kubernetes OOM (exit code 137). Chẩn đoán bằng pprof goroutine profile, chặn đứng qua goleak trong CI và áp dụng Go 1.26 goroutine leak detection. Một pod Kubernetes đột ngột khởi động lại với mã thoát (exit code) 137. Biểu đồ giám sát bộ nhớ (memory metrics dashboard) hiển thị một mô hình bậc thang tăng dần đều đặn kéo dài suốt ba ngày. Không có bất kỳ log panic nào trong stdout, không có lỗi database, và không có mức tăng đột biến CPU bất thường nào. Chỉ là một cái chết êm đềm và từ từ do lỗi OOM (Out Of Memory). ...