Profiling in Production

The four profiles

Go has profiling built into the runtime — no agent, no rebuild. Each profile answers a different “why”:

graph TD
Q["service is unhealthy"] --> CPU["CPU profile<br/>which functions burn CPU?"]
Q --> HEAP["heap profile<br/>what allocates / leaks memory?"]
Q --> GR["goroutine profile<br/>are goroutines leaking / stuck?"]
Q --> BLK["block / mutex profile<br/>where do goroutines wait on locks?"]

• CPU — samples where the program spends CPU time → flame graph of hot functions.
• Heap — attributes allocations to call sites → find allocation/GC pressure and leaks.
• Goroutine — a snapshot of every goroutine’s stack → spot leaks (count only grows) and deadlocks.
• Block / Mutex — where goroutines wait on channels/locks → contention.

See it: a cheap runtime health snapshot

You don’t need a profiler running to read the basics — runtime exposes goroutine count and allocation stats live. This runs here and prints stable facts (booleans/deltas, so it’s deterministic):

package main

import (
"fmt"
"runtime"
)

func main() {
var m1 runtime.MemStats
runtime.ReadMemStats(&m1)
g0 := runtime.NumGoroutine()

// Allocate ~100k short-lived objects (the kind a heap profile would flag).
sink := make([][]byte, 0, 100_000)
for i := 0; i < 100_000; i++ {
	sink = append(sink, make([]byte, 16))
}

var m2 runtime.MemStats
runtime.ReadMemStats(&m2)
fmt.Println("goroutines stable:", runtime.NumGoroutine() == g0)
fmt.Println("allocations happened:", m2.Mallocs-m1.Mallocs >= 100_000)
fmt.Println("GC ran at least 0 times:", m2.NumGC >= m1.NumGC)
_ = sink
}

In production you expose the real profiler. Importing net/http/pprof registers endpoints you pull profiles from (fenced — needs a server):

import _ "net/http/pprof" // registers /debug/pprof/* on the default mux

// Expose it on a SEPARATE, internal-only port — never the public listener.
go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }()

// Then, against a running service:
//   go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30   # CPU
//   go tool pprof http://localhost:6060/debug/pprof/heap                  # memory
//   curl http://localhost:6060/debug/pprof/goroutine?debug=2             # stacks

go tool pprof then shows top functions, call graphs, and flame graphs. The pprof page in the stdlib track covers the analysis workflow in depth.

Continuous profiling

A one-off profile catches a problem you’re already chasing. Continuous profiling (Pyroscope, Parca, Grafana/Datadog profilers) scrapes the pprof endpoints on a low duty cycle and stores profiles over time — so you can compare “before vs after a deploy,” find a slow regression, and profile an incident after it happened. It’s the profiling equivalent of always-on metrics.

See also

• Profiling with pprof (stdlib) — the go tool pprof analysis workflow.
• GC & stacks (concurrency) — reducing the allocations the heap profile finds.
• Goroutines — the leaks the goroutine profile catches.
• Metrics with Prometheus — the alert that sends you to profile.

Next: decoupling services with asynchronous messaging — message queues.

Related topics