Go pprof profile 采集时间太短看不到热点怎么办

Go 服务用 pprof 采集 CPU profile 后，如果 top 里没有预期函数，最常见的原因不是 pprof 失效，而是采样窗口太短，或者采集期间目标请求没有持续经过那段代码。处理时先确认入口是 /debug/pprof/profile，再让问题负载覆盖完整窗口；窗口仍不够就显式增加 seconds，最后用 flat、cum 和 list 交叉判断。

先分清采样窗口短，还是目标代码根本没被覆盖

net/http/pprof 的 Profile 处理器返回 CPU profile；官方文档说明，不传参数时采集时长是 30 秒，也可以用 seconds=N 指定窗口。它记录的是采样期间观察到的 CPU 活动，不是把服务启动以来的全部调用做一次统计。

所以“看不到热点”至少有两种含义：一是目标函数确实很忙，但只采了几秒，样本还没有稳定；二是 profile 期间流量主要走了缓存、空结果或其他分支，目标函数根本没有足够机会被采到。第二种情况继续把窗口从 10 秒拉到 60 秒，也只是更稳定地证明这段负载没有覆盖目标路径。

用 seconds 参数采集一段有代表性的 CPU profile

先保留一个可复现的基线命令。假设服务的 pprof 端口是 6060：

# 采集 30 秒 CPU profile，先建立基线
go tool pprof -seconds=30 -output=cpu-30s.pb.gz \
  http://127.0.0.1:6060/debug/pprof/profile

# 如果目标请求较稀疏，显式延长到 60 秒
go tool pprof -seconds=60 -output=cpu-60s.pb.gz \
  http://127.0.0.1:6060/debug/pprof/profile

也可以直接把参数写在 URL 上，例如 curl -o cpu-60s.pb.gz 'http://127.0.0.1:6060/debug/pprof/profile?seconds=60'。命令本身只负责采集，采集期间还要用稳定的压测请求或真实回放持续触发目标接口。不要一边采集一边等待流量自然到来，否则 profile 里最醒目的可能只是健康检查、日志或空闲调度。

用 top、list 和 cum 判断热点是否真的出现

打开 profile 后先看总览，不要只盯着函数名：

# 进入交互式 pprof
go tool pprof cpu-60s.pb.gz

# 在 pprof 提示符中查看自身耗时和累计耗时
(pprof) top
(pprof) top -cum

# 查看某个函数对应的源码行
(pprof) list handleRequest

flat 是函数自身消耗的样本，适合发现某个函数内部的计算、编码或锁等待是否直接占 CPU；cum 把被调用函数的样本也归到当前调用链，适合寻找“入口函数很热，但真正耗时在下层”的情况。一个函数在 cum 排名靠前、flat 很低，并不表示它本身慢。

如果 list 能看到目标函数，但样本集中在另一行，说明路径被覆盖了，只是热点判断需要更细的负载拆分。若三个命令都没有目标函数，优先回到请求入口和采集窗口检查，而不是马上修改代码。

把采样结果变成可重复的排查清单

每次采集至少记录四项：profile 类型、seconds 值、负载入口和采集期间的请求比例。对比两个 profile 时，先保证请求类型和并发条件相近，再比较热点；否则差异可能来自输入数据或缓存状态，而不是代码改动。

如果问题是内存增长，不要用 CPU profile 代替 heap；如果问题是 goroutine 阻塞、锁竞争或调度延迟，应分别考虑 block、mutex、goroutine 或 trace。pprof 工具很多，但关键是让 profile 类型和问题边界匹配。窗口拉长只能改善采样稳定性，不能把错误的观测对象变成正确答案。

相关问题

CPU profile 一定要采集 60 秒吗？

不一定。先用默认 30 秒建立基线；目标请求很稀疏时再延长，并优先保证窗口内有足够多的同类请求。

为什么 top 的 cum 很高但 flat 很低？

这通常表示入口函数本身只做调度，累计耗时主要来自它调用的下层函数，应继续用 list 或调用关系定位下层热点。

profile 文件有内容但看不到业务函数怎么办？

先确认采集 URL 是 CPU profile，再检查目标请求是否在采集窗口内真实经过该函数；如果问题是锁、阻塞或内存，应换用匹配的 profile 类型。