Go runtime/pprof调整采样间隔而不误读结果的参数边界

Go 做 CPU profiling 时，采样间隔不能脱离采样窗口来解释。先记住一个实用结论：runtime.SetCPUProfileRate 改的是每秒采样次数，runtime/pprof.StartCPUProfile 决定采样写入哪个文件以及何时停止；两者都不会替你消除负载波动。对同一个任务比较 profile 时，应固定采样率、运行时长和请求负载，再看样本数与百分比。

先把三个容易混淆的量分开

采样率是每秒尝试记录多少次 CPU 栈；采样窗口是 profiling 持续多久；样本总量大致由两者共同决定。比如同一接口运行 10 秒，把采样率从 100 调到 200，报告中的总样本可能增加，但这并不表示接口吞吐提高了一倍。比例是“某函数占总样本的份额”，不是函数实际被调用的次数。

我通常先把采样窗口固定为一次完整的压测阶段，只在样本明显不足或需要区分很短的热点时调整采样率。若两次测试的窗口、并发数和请求数据不同，哪怕 pprof 的百分比很接近，也不应该直接下性能结论。

用 StartCPUProfile 包住可比的工作区间

独立程序可以显式控制 profile 文件。下面的例子把采样参数和工作时长放在一起记录，重点是处理创建文件、启动失败和停止 flush。示例中的 SetCPUProfileRate 只在开始采集前设置一次；如果进程已经由别的组件开启 CPU profiling，不要再次启动。

package main

import (
    "log"
    "os"
    "runtime"
    "runtime/pprof"
    "time"
)

func main() {
    // 只在采集前设置一次，便于让不同 profile 使用同一基线。
    runtime.SetCPUProfileRate(100)

    f, err := os.Create("cpu.prof")
    if err != nil {
        log.Fatal(err)
    }
    defer f.Close() // 关闭文件，避免句柄泄漏。

    if err := pprof.StartCPUProfile(f); err != nil {
        log.Fatal(err) // 已有 profiling 或写入失败时立即停止。
    }
    runWorkload()
    pprof.StopCPUProfile() // 停止并 flush，随后再读取 cpu.prof。
}

func runWorkload() {
    // 用固定时长模拟可重复工作区间；真实压测应替换为稳定负载。
    time.Sleep(10 * time.Second)
}

如果用的是 HTTP 服务，net/http/pprof 的 profile 端点也有自己的采集时长；这时不要一边改变服务端采样设置，一边比较不同长度的下载结果。采集结束后再用 go tool pprof 打开文件，先记录参数，再分析函数。

调高采样率时，边界在“可比”而不是“越大越好”

runtime.SetCPUProfileRate(hz) 的参数单位是每秒采样次数。频率升高能让短暂热点更容易出现在样本中，但也会增加采集开销和解释噪声；频率降低则更适合长时间观察总体结构。生产环境我更愿意先在低风险流量上灰度，并把 rate、持续时间、版本和负载写入采集记录。

pprof 结果要同时看 flat、cum 和总样本

可以先执行：

# 查看占用 CPU 样本最多的函数，先看直接开销。
go tool pprof -top cpu.prof

# 按调用链累计开销排序，定位上层入口。
go tool pprof -top -cum cpu.prof

flat 更接近函数自身运行时占据的样本，cum 会把被调用函数的样本沿调用链累计。两者不一致很正常：一个入口函数可能自身很轻，但它调用的下层函数很重。比较两个 profile 时，先确认总样本、采集时长和 rate，再看热点排序；只看“某函数占 20%”而不看分母，最容易误读。

常见问题

把采样率调高就一定更准确吗？

不一定。它提高的是观测密度，不能替代稳定负载和重复采集；如果采集开销影响了业务，结果反而失真。

为什么两次 profile 的总样本不同？

采样率、持续时间、进程是否完整运行到停止点都可能造成差异。先对齐这三个条件，再比较函数比例。

能在运行中反复调用 SetCPUProfileRate 吗？

不建议把它当动态调参开关。采集前确定基线，采集后保存参数；需要另一种频率时开启独立、可比较的采集轮次。

把采样率当成实验参数，而不是性能开关，Go runtime/pprof 的结果会更稳定：先固定窗口和负载，再选择足够的样本量，最后用 flat、cum 与总样本共同解释。