Apache Cloudberry 向量化实践（二）：如何识别和定位向量化系统的性能瓶颈？

如何系统性识别并定位向量化执行链路中的性能瓶颈？本文将结合分析方法论与实践案例，帮助大家建立起优化的基本盘。

性能问题从何而来？

向量化系统中的性能瓶颈往往不易察觉。它可能是某个操作符计算效率低下，也可能是某次调度延迟过大，甚至是系统某一阶段发生了资源争抢。大致来看，性能瓶颈来源可分为以下几类：

• 计算瓶颈（on-CPU）：如表达式编译低效、算子计算逻辑复杂等。

• 等待瓶颈（off-CPU）：如线程调度延迟、磁盘或网络 IO 阻塞等。

• 资源瓶颈：如内存不够导致频繁 GC、网络带宽打满等。

要定位问题，我们首先需要收集足够的数据、刻画清晰的运行画像。

构建业务负载画像与数据采集链路

性能调优的第一步是建立业务负载的“粗画像”，即通过基础指标了解系统在运行过程中的状态，判断是计算密集型、IO 密集型还是混合型负载。这一步需要依靠一系列标准工具：

基础观察工具链：

这些工具可以帮助我们在“系统级”观察性能问题。但对于向量化系统的细粒度分析，这还远远不够。我们需要更强大的“调用链级”工具。

火焰图与 on-CPU/off-CPU 分析

火焰图（Flame Graph）是目前最有效的性能可视化工具之一，它能以调用栈的方式直观展示程序在什么地方花了最多时间。

如何采集与分析火焰图？

Step 1：采集栈信息

安装工具

git clone https://github.com/brendangregg/FlameGraph

采集 on-CPU 数据

oncpu -df -p $(pgrep -nx postgres) 10 > out_oncpu.stacks

采集 off-CPU 数据（等待时间）

offcpu -df -p $(pgrep -nx postgres) 10 > out_offcpu.stacks

Step 2：生成火焰图

./flamegraph.pl --color=io --title="ON-CPU Time Flame Graph" out_oncpu.stacks > oncpu.svg

通过火焰图我们可以回答两个核心问题：

• 哪段代码在 CPU 上消耗时间最多？（on-CPU）

• 哪些任务被频繁挂起等待？（off-CPU）

案例分析：Cloudberry 中的 take + filter 性能问题

在 Apache Cloudberry 的一次性能排查中，我们发现某些查询在节点数增多后反而变慢。经过初步分析，查询涉及大量的 take 和 filter 操作。

分析手段

使用 perf + 火焰图进行分析，观察结果如下：

• on-CPU 火焰图：大量时间集中在 EvalVector 表达式求值函数上，尤其是字符串函数处理。

• 调用栈分析：明显展现出数据在多个字段上进行 filter 的逻辑链条。

问题结论

• filter 表达式未完全向量化，部分路径仍保留逐行处理逻辑。

• take 操作在多个分区中重复计算，造成了不必要的数据传输。

• 系统缺乏轻量级调度机制，导致 CPU 核心使用不均衡。

工具方法总结：适用范围与阶段建议

为了帮助更广泛的系统调优需求，我们对常见工具进行总结：

其中，bcc/bpftrace 是现代系统调优的重要利器，适合调研内核行为、调度延迟、线程切换等细粒度性能问题。

向量化系统带来的高性能红利，也意味着更高的系统复杂度。只有具备系统性分析思维，结合实际工具链，才能真正掌握“瓶颈识别”这一核心能力。

本文介绍的方法不仅适用于 Apache Cloudberry，也适用于其他现代 MPP 数据库系统。在性能调优的世界里，没有“银弹”，但有一套可复用的方法论。希望为大家构建起系统性能分析的基本盘，助大家在复杂系统中从容破局。