问题描述
我们的管道是基于 Apache Beam Go SDK 开发的。我试图通过设置标志 --cpu_profiling=gs://gs_location
: https://github.com/apache/beam/blob/master/sdks/go/pkg/beam/runners/dataflow/dataflow.go
该作业以 16.636 小时的 vcpu 和最多 104 名工作人员完成:
结果在指定的GCS位置,记录了一堆名称为“profprocess_bundle-*”的文件:
然后我下载了这些文件,将它们全部解压缩,并使用 pprof (https://github.com/google/pprof) 将结果可视化:
这里是我的问题:
-
分析结果中的总时间是如何收集的?采样时间(1.06 小时)比 Dataflow 报告的 vcpu 时间(16.626 小时)短得多。
-
文件名“profprocess_bundle-*”中的数字是多少?我在想它可能对应于工人的索引。但数量的最大值大于工人数量,且数量不连续。最大数量是 122,但只有 66 个文件。
解决方法
当您设置 --cpu_profiling=true
时,分析在 SDK 工作程序开始处理包时开始(一批输入元素将通过管道 DAG 的子图,有时也称为工作项)并在加工完成。一个作业可以包含许多包。这就是为什么总 vCPU 时间会大于采样周期。
如前所述,profprocess_bundle-* 中的数字代表正在分析的包 ID。