Go · pprof 性能分析

场景 1 · 线上 CPU 85% 告警: 30 秒采样定位热点函数

大促前网关 CPU 打满, 先抓画像再说话, 不猜:

// curl -o cpu.prof http://10.0.4.12:6060/debug/pprof/profile?seconds=30
// go tool pprof svc cpu.prof   交互里两步定位:
//   top10          → crypto/sha256.block flat 41%
//   list hashPassword → 热点行如下:
func hashPassword(pw []byte) [32]byte {
    h := sha256.Sum256(pw)
    for i := 0; i < 10000; i++ {          // 这一行占全进程 41%
        h = sha256.Sum256(h[:])               // 登录场景无需 1 万轮
    }
    return h
}
// 降到 210 轮 (OWASP 建议) 后: CPU 41% → 3%, 登录 P99 无感

场景 2 · 内存 6 小时涨 4GB 不降: heap 差分抓增长点

曲线只上不下, 两份 heap 做差分, 直接看"这 6 小时谁多占了":

// curl -o h1.prof http://svc:6060/debug/pprof/heap
// 6h 后再采 h2.prof, 然后差分 (只看增量):
// go tool pprof -base h1.prof svc h2.prof
// (pprof) top -inuse_space
//   +1.9GB  62%  main.newSessionManager  → map 只增不删
func (m *SessionManager) sweep() {
    for id, s := range m.sessions {
        if s.expired() {
            delete(m.sessions, id)          // 修复: 清理函数根本没实现
        }
    }
}

修复后 6h 内存曲线由斜线变平线; 差分法比单看一份 profile 快一个量级。

场景 3 · goroutine 2k 涨到 90k: dump 全量栈找泄漏点

debug=1 的"计数+栈摘要"最适合数出"哪类 goroutine 涨了":

// curl http://svc:6060/debug/pprof/goroutine?debug=1 | head -30
// 85000 @ 0x1023f4 ... main.(*Hub).subscribe
// 原 bug: 无缓冲 resp chan, 发送方退出后没人 close
func (h *Hub) subscribe(ctx context.Context) Msg {
    resp := make(chan Msg, 1)                  // 修复1: 缓冲 1
    h.route <- sub{out: resp}
    select {                                   // 修复2: 挂退出分支
    case m := <-resp:
        return m
    case <-ctx.Done():
        return Msg{}
    }
}

场景 4 · mutex profile 定位热点锁, 改分片

P99 高但 CPU 不忙, 九成是锁排队; mutex 画像直接点名持有者:

runtime.SetMutexProfileFraction(100)      // 默认关, 必须显式开
// 压测后: go tool pprof svc http://.../mutex
// top -cum: 68% 竞争集中在 record() 的全局锁
var mu sync.Mutex                            // 全局一把: 全维度写排队
func record(dim string, v float64) {
    mu.Lock(); agg[dim] += v; mu.Unlock()
}
// 修复: 256 把分片锁, 竞争面降到 1/256
var shards [256]sync.Mutex
func record2(dim string, v float64) {
    i := fnv32(dim) & 255
    shards[i].Lock(); agg[dim] += v; shards[i].Unlock()
}

锁语义细节看 sync 页; 这里强调: 分片是 mutex profile 给出的标准答案之一。

场景 5 · benchmark + ReportAllocs 验证优化前后

"感觉变快了"不算数, allocs/op 与 ns/op 用数据回答:

func BenchmarkRender(b *testing.B) {
    b.ReportAllocs()                           // 输出 B/op, allocs/op
    tpl := mustParse(userTemplate)
    b.ResetTimer()                            // 准备期不计入
    for i := 0; i < b.N; i++ {
        sink = render(tpl, fixture)             // 消费结果, 防优化掉
    }
}
// go test -bench=Render -count=10 | tee new.txt
// benchstat old.txt new.txt:
//   old  14231 ns/op   48 B/op   3 allocs/op
//   new   5210 ns/op    0 B/op   0 allocs/op   (sync.Pool + 预分配)

场景 6 · 生产 pprof 端口收敛: 只绑 localhost + 临时拉起

:6060 暴露公网等于把内部结构、路径、密钥线索白送攻击者:

mux := http.NewServeMux()
mux.Handle("/debug/pprof/", http.DefaultServeMux) // 只挂自己的 mux
go func() {
    ln, err := net.Listen("tcp", "127.0.0.1:6060") // 1. 只绑回环
    if err == nil { http.Serve(ln, mux) }          //    port-forward 进来采
}()
// 2. 必须对内网开放时: 网络策略 + basic auth 中间件
// 3. 平时不开, 告警时 --pprof=true 临时拉起, 排查完关掉

场景 7 · trace 发现调度延迟与 GC 停顿

pprof 只说"哪里热", "为什么周期性卡"要看时间轴:

// curl -o trace.out http://svc:6060/debug/pprof/trace?seconds=5
// go tool trace trace.out
// 时间轴: 每 200ms 一根 8ms 的 STW + 大片 runnable 排队
// 结论: 分配率过高 → GC 频繁 + G 堆积 (与 GC 页结论互相印证)
// 优化 (sync.Pool 复用 + 写缓冲合并) 后再抓一次:
//   GC 周期 200ms → 1.6s, 接口 P99 从 34ms → 11ms

场景 8 · CI 里跑 bench 防性能回退

性能劣化多半是"顺手"引入的, PR 门禁用 benchstat 把它拦下:

name: bench-guard
on: [pull_request]
jobs:
  compare:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with: { go-version: '1.23' }
      - run: go test -bench=. -count=10 ./... | tee new.txt
      - run: git checkout main && go test -bench=. -count=10 ./... | tee old.txt
      - run: benchstat old.txt new.txt

count=10 是给 benchstat 做统计显著性用的; 单次 bench 的波动比想象中大。

场景 9 · 容器内导出 profile, 本地分析

线上是 alpine 容器没有 go 工具链? 导出文件带回来, 二进制版本对上就行:

kubectl exec svc/gateway -n prod -- \
  curl -s -o /tmp/cpu.prof "localhost:6060/debug/pprof/profile?seconds=30"
kubectl cp prod/gateway:/tmp/cpu.prof ./cpu.prof
// 用构建产物里同一个二进制 (符号匹配是生死线):
go tool pprof -http=:8081 ./dist/gateway-v1.47.2 ./cpu.prof
// list 报 no source: 回到模块根目录跑, 或加 -source_path

场景 10 · 压测前的基线画像流程

新网关上线前固定动作: 基线 → 压测 → 差分, 不带病发布:

curl -o base_cpu.prof  http://gw:6060/debug/pprof/profile?seconds=30
curl -o base_heap.prof http://gw:6060/debug/pprof/heap
curl -o base_gor.prof  http://gw:6060/debug/pprof/goroutine
wrk -t8 -c512 -d120s http://gw.internal/api/search
curl -o load_heap.prof http://gw:6060/debug/pprof/heap
go tool pprof -base base_heap.prof ./gateway load_heap.prof

发布单记下 QPS / P99 / RSS / allocs/op / goroutine 数五项; 任一劣化超 15% 先优化再上线。