Go 性能排查：pprof、阻塞与压测复核

本轮只做理论正文与源码静态复核；下列命令、示例和测试均未执行。已有输出按代码推演或历史记录理解，不作为本轮运行证据。

前置：并发与生命周期、测试与基准。先明确观察到的延迟、吞吐或资源异常，再决定采样方式；指标提供趋势，profile 提供调用栈归因，二者不能互相代替。

接入诊断端点

下面是独立诊断服务的最小例子；在实际进程中接入时，应与业务服务的启动和关闭一起管理。

package main

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

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/debug/pprof/", pprof.Index)
    mux.HandleFunc("/debug/pprof/cmdline", pprof.Cmdline)
    mux.HandleFunc("/debug/pprof/profile", pprof.Profile)
    mux.HandleFunc("/debug/pprof/symbol", pprof.Symbol)
    mux.HandleFunc("/debug/pprof/trace", pprof.Trace)
    server := &http.Server{
        Addr: "127.0.0.1:6060",
        Handler: mux,
        ReadHeaderTimeout: 5 * time.Second,
    }
    log.Fatal(server.ListenAndServe())
}

监听回环地址可用于本地诊断，远程访问经受控通道。独立 mux 避免业务路由无意暴露诊断端点。Prometheus 的 /metrics 是另一套指标处理器，不是启用 pprof 的前提。

选择采样类型

现象	证据	解释边界
CPU 高	/debug/pprof/profile?seconds=30	CPU 时间落在哪些调用栈，不等于请求墙钟耗时
活跃堆持续增长	heap，查看 inuse_space	当前保留对象的采样，不等于进程 RSS 全部内存
分配频繁、GC 压力	allocs，查看 alloc_space	累积分配可能高，但并非全部仍被持有
goroutine 数持续增长	goroutine 文本栈与多时点对照	确认卡在哪个 channel、锁或外部调用
锁竞争或同步等待	mutex、block	需按场景启用相应采样，采样有开销
调度或时序异常	trace	补充调度事件，不能只看 CPU 火焰图

go tool pprof -proto -output=cpu.pb.gz "http://127.0.0.1:6060/debug/pprof/profile?seconds=30"
go tool pprof -proto -output=heap.pb.gz http://127.0.0.1:6060/debug/pprof/heap
go tool pprof -http=127.0.0.1:8081 cpu.pb.gz

交互命令 top 看热点，list FunctionName 结合源码，web 图形功能可能需要 Graphviz。区分 flat（函数自身）与 cum（含下游调用）。分析时保留相匹配的二进制、源码、版本和采样时间窗。

压测与定位顺序

1. 固定场景、构建版本、数据量和成功标准，记录延迟分位数、错误率及依赖耗时。
2. 在可控环境中逐步提高并发，观察 CPU、RSS、goroutine、磁盘与网络，区分服务自身饱和与依赖瓶颈。
3. 在异常时间窗采样。CPU 高看调用栈；CPU 不高但延迟高，重点检查排队、锁和外部调用等待。
4. 内存增长对比多个时点的活跃堆与对象持有链，再判断缓存、正常积累或未释放引用，不单凭一次 RSS 判定泄漏。
5. 改动后用相同负载和时间窗复测，核对功能、错误率、尾延迟与资源成本。

Linux 可配合 htop -p <pid>、iostat 等系统工具；工具可用性和字段随系统版本变化。网络队列暂时非零并不能直接证明应用死锁，应结合持续时间、连接状态和调用栈。Go GC 管理的堆对象通常先用 heap/profile 与代码持有关系排查，不能把 Valgrind 作为所有 Go 内存问题的默认入口。

常见误判

• 在 CPU 火焰图找不到高耗时函数，不代表外部 RPC 没有拖慢请求；等待不会按墙钟耗时完整体现在 CPU 样本中。
• runtime 热点本身不说明运行时有缺陷，要继续追踪分配量、同步方式与业务栈。
• 单次测试中的某依赖 QPS 上限只适用于当时环境，不能作为其他机器、数据量和版本的容量结论。

练习与参考

运行诊断例子，抓取 heap 与 goroutine，确认 profile 可被 pprof 打开；随后在自己的可终止计算例子上比较 CPU 与 heap 关注的指标。官方文档：net/http/pprof、诊断指南、GC 指南。

诊断练习参考判断

题目：这个最小进程几乎没有业务计算，30秒CPU采样很小或没有明显业务热点，是否故障？提示：区分采样时间窗和活跃CPU工作。

参考答案

不能据此认定故障。空闲服务预期主要等待；heap与goroutine描述保留对象和等待栈。mutex/block默认采样设置还需按目标进程明确配置，端点能访问不代表已经采到锁等待事件。此进程未实现优雅关闭，仅为最小诊断端点；完整生命周期见课程，不以log.Fatal退出作为清理示例。