Go PGO 怎样合并多个代表性 profile

Go PGO 合并多个代表性 profile，核心命令只有一条：go tool pprof -proto a.pprof b.pprof > merged.pprof。但它不是把几个文件“平均一下”，而是把输入 profile 的样本直接相加。因此，采样时长不一致、工作负载占比不同或 SampleType 不兼容，都会让合并结果偏离你想代表的线上流量。

稳妥做法是：先确认这些 profile 属于同一个构建目标，再尽量使用相同的采样窗口；如果多个工作负载要共用一个二进制，就按总工作负载选择代表性输入并合并，否则保留不同 profile，分别构建更合适的版本。

先判断多个 profile 是否值得合并

PGO 使用的是 CPU pprof profile。多个实例、多个时间段或多个请求类型的 profile，只有在它们共同描述同一个构建目标时，合并才有意义。比如一个 API 服务的订单请求、批处理任务和后台任务都由同一个二进制承载，合并可以得到更接近 fleet-wide 的共同热点；如果它们本来就对应不同的二进制或完全不同的产品负载，强行合并会把优化目标搅在一起。

判断时先问三个问题：profile 是否都是 CPU 采样；样本是否来自同一类程序和相近的代码版本；最终是否真的只想产出一个通用构建。如果答案分别是“是、基本是、是”，再进入合并步骤。

先把采样窗口和代表性固定下来

Go 官方文档特别提醒，pprof 的合并是样本相加，并不会自动按照每个文件的墙上时间做归一化。假设一个 profile 采了 30 秒，另一个采了 120 秒，后者在 merged profile 中天然拥有更多样本；如果两者只是同一服务的不同时长切片，这通常会把长采样窗口过度放大。

对持续运行的服务，比较稳妥的做法是从不同实例或不同时间段收集相同秒数的 CPU profile，并记录实例承担的流量范围。不要只因为文件名不同就认为它们代表不同样本，也不要在低流量实例刚好空闲时把它当成全站画像。

# 每个实例使用相同的 30 秒窗口，便于后续把样本放在同一权重尺度上。
curl -o api-a.pprof 'http://127.0.0.1:6060/debug/pprof/profile?seconds=30'
curl -o api-b.pprof 'http://127.0.0.1:6060/debug/pprof/profile?seconds=30'

# 文件名只做来源记录；真正的代表性仍取决于实例负载和采样时段。
mv api-a.pprof profile-order-30s.pprof
mv api-b.pprof profile-batch-30s.pprof

如果一次采样只覆盖了某个偶然请求类型，就不要用更多同类文件简单堆出“稳定画像”。更好的输入是覆盖主要流量的实例和时间段；对不同工作负载，还要决定它们在最终构建中应该各自占多大份额。

用 go tool pprof 合并 CPU profile

准备好同一尺度的输入后，使用 -proto 输出 pprof 格式的合并文件：

# pprof 会把多个输入的样本合并，输出文件仍保持 pprof 格式。
go tool pprof -proto \
  profile-order-30s.pprof \
  profile-batch-30s.pprof \
  > merged.pprof

# 用文本汇总快速确认合并文件可被 pprof 读取。
go tool pprof -text merged.pprof

这里的 -proto 是输出格式选项；它不会替你判断输入是否代表同一个线上画像。合并前后应保留来源记录，例如采样实例、采样秒数、主要请求类型和代码版本，这些信息不在“命令成功”里自动补全。

让不同工作负载的权重接近真实流量

合并多个工作负载时，不能只按文件数量投票。一个每小时只运行一次的批处理文件，可能不应该和持续承载绝大多数请求的 API 文件拥有相同影响力；反过来，如果批处理本身占据了主要 CPU 预算，也不能因为它文件少就忽略。

Go PGO 文档给出的选择是：分别为不同工作负载构建多个版本；选最重要的工作负载生成单一版本；或者根据各工作负载的总 footprint 合并成一个 fleet-wide profile。最后一种方案追求的是所有工作负载的中等收益，而不是让每一个工作负载都达到单独优化时的峰值。

别忽略 SampleType 和源码平台差异

pprof 的合并要求输入 profile 的 sample type 和 period type 兼容。PGO 要的是代表 CPU 时间的 profile；把 heap、goroutine 等其他类型的 profile 当成 PGO 输入，解决不了“合并”问题，反而会让输入失去目标语义。来自不同工具的 profile 也要确认已经符号化，并保留函数名和内联栈等 PGO 所需信息。

不同 GOOS/GOARCH 的 profile 可以合并或复用，但平台相关源码如果无法匹配，相关代码就不会得到对应优化。源码重命名、函数移动到其他包或热点函数内部大改，也可能减少旧 profile 的匹配范围。于是，合并不是永久资产：代码结构和流量改变后，要重新收集新的代表性 profile。

把 merged.pprof 接入构建

最直接的方式是在构建时显式指定合并后的文件：

# 只为这个主程序使用合并 profile，避免把同一画像误套给不同二进制。
go build -pgo=merged.pprof -o bin/api ./cmd/api

# 如果把它放在主包目录并命名为 default.pgo，可让 go build 自动发现。
cp merged.pprof ./cmd/api/default.pgo
go build -pgo=auto -o bin/api ./cmd/api

当一次命令构建多个 main package 时，显式传入的 -pgo 路径会应用到所有 main package；如果它们的工作负载不同，通常应拆成多个构建命令，分别传入对应 profile。构建后不要只看编译成功，应该用与采样画像相近的流量观察收益，下一轮再收集生产 profile。

发布前可以保留的最小清单

• 所有输入都是 CPU pprof，并且 SampleType、PeriodType 兼容。
• 采样窗口尽量相同，记录实例、时段、代码版本和工作负载。
• 明确是单一通用二进制，还是按工作负载分别构建。
• 合并命令使用 go tool pprof -proto，输出文件作为 -pgo 或 default.pgo。
• 源码或平台发生明显变化后重新采样，不把旧画像当成永久真相。

相关问题

profile 采样时间不同还能合并吗？

可以合并，但结果是样本直接相加，长窗口会自然获得更大权重。若这些文件只是同一类服务的时间切片，优先统一采样时长；若时长差异本身代表不同工作负载 footprint，就应明确记录并按目标解释权重。

多个 profile 一定比一个 profile 好吗？

不一定。多个输入能降低单实例、单时段偏差，但前提是它们覆盖的工作负载真实且边界清楚。噪声输入越多，单一通用构建越可能变成折中方案。

为什么不直接把所有 profile 文件改名成 default.pgo？

default.pgo 只能指向一个合并后的输入。多个文件需要先通过 pprof 形成一个 profile；如果负载本来应该分开优化，就分别放在对应主包或构建命令中，而不是伪装成同一个画像。

本文事实依据：Go 官方 PGO 文档 https://go.dev/doc/pgo、Go Wiki PGO Tools https://go.dev/wiki/PGO-Tools。