Menu

Go Profiling in Production: pprof, Flamegraphs and Memory Leaks
πŸ“°

Go Profiling in Production: pprof, Flamegraphs and Memory Leaks

DEV Community: goΒ·Ayi NEDJIMIΒ·1 day ago
#i0hqWB4C
#devtogo#devto#dev#pprof#time
Reading 0:00
15s threshold

You deploy a Go service that handles 200 req/s in staging just fine. In production, latency climbs after six hours, memory keeps growing, and you have no idea which goroutine is the culprit. Go's built-in profiling toolchain can answer this β€” but only if you know how to use it correctly without adding overhead or security holes.

Enabling pprof Without Exposing It to the Internet

The most common advice is to add import _ "net/http/pprof" and start an HTTP server. That works, but shipping a /debug/pprof endpoint on your public API is a concrete security risk β€” it exposes memory contents, goroutine stacks, and CPU traces to anyone who can reach the port. Restrict it to localhost or a separate internal port with an explicit listener:

package main

import ( "log" "net" "net/http" _ "net/http/pprof" )

func startProfilingServer () { ln , err := net . Listen ( "tcp" , "127.0.0.1:6060" ) if err != nil { log . Fatalf ( "pprof listen: %v" , err ) } go func () { if err := http .…

Continue reading β€” create a free account

Join HashtagPLUS to read full articles, follow hashtags, vote, and join the conversation.