在 NVIDIA Vera 上对 DuckDB v2.0-dev 进行基准测试
2026-10-13 3 分钟阅读
Gábor Szárnyas
TL;DR： 我们用完整的 TPC-H 工作负载在规模因子 1,000 上测试了 NVIDIA 的新 Vera CPU。
我们喜欢在各种新硬件上运行基准测试。这通常包括一些相当奇特的硬件——有时我们需要编译新的 DuckDB 二进制文件。这一次，我们与 NVIDIA 团队合作，拿到了他们面向代理工作负载的新 Vera 芯片。
Vera CPU 带有 88 个“Olympus”核心，以及高达每秒 1.2 太字节（TB/s）的内存带宽。更重要的是，Vera 运行 arm64 二进制文件——所以它无需任何修改就能运行 DuckDB 的常规构建。
为了看看这个新硬件的表现，我们在规模因子 1,000 上运行了完整的 TPC-H 基准测试（不只是读取查询！）。我们的设置包括两个服务器平台：一个 x86 基线（Intel Xeon 6）和 NVIDIA Vera。
环境
系统设置
两台机器都运行 Ubuntu 26.04。它们的硬件包括 768 GB 内存和一块 3+ TB 存储的 NVMe SSD，格式化为 ext4。在撰写本文时，DuckDB v2.0 尚未发布，所以我们使用了一个预览构建，1.6.0.dev379。
为了运行实验，我们使用了 duckdb-tpch 基准测试工具。要重建我们的基准测试环境，请参见下面的脚本。
点击这里展开设置脚本。
提示
为了高效生成大规模 TPC-H 数据集，该仓库使用了极好的 tpchgen-cli 工具，这是 TPC-H 数据生成器的并行 Rust 重写。它还使用旧生成器来产生更新和查询流。
这个工作负载相对大规模（SF1,000），并且在吞吐量运行期间高度并发。为了让 DuckDB 发挥最佳性能，我们设置了以下标志：
SET block_allocator_memory = '500G';
SET allocator_background_threads = true;
x86 基线：Intel Xeon 6
x86 基线设置使用了一颗 Intel Xeon 6 CPU。该 CPU 有 96 个核心并支持超线程，产生 192 个线程。然而，我们发现 DuckDB 在使用 96 个线程时表现最佳，所以我们相应地配置了它：
SET threads = 96;
NVIDIA Vera
第二台机器有 NVIDIA Vera CPU，它包含 88 个核心并支持空间多线程（Spatial Multithreading）。我们在双路系统上进行了基准测试，但使用 numactl 命令把 DuckDB 限制到单个插槽：
numactl --cpunodebind=0 --membind=0 python3 benchmark.py
为了确保 DuckDB 不会使用比可用数量更多的线程，我们固定了线程数：
SET threads = 88;
基准测试运行和结果
我们进行了一次初始预热运行并丢弃其结果。然后，我们连续进行了三次完整运行，并取 QphH@Size 综合得分的中位值：
| x86 QphH@Size | Vera QphH@Size | |
|---|---|---|
| 运行 1 | 2,120,588.82 | 3,073,292.99 |
| 运行 2 | 2,022,795.01 | 3,131,306.27 |
| 运行 3 | 2,109,782.19 | 3,052,102.87 |
| 中位得分 | 2,109,782.19 | 3,073,292.99 |
结果显示，Vera 平台在 TPC-H SF1,000 上相比 x86 基线（Intel Xeon 6）有 46% 的性能优势。事实上，如果我们通过官方 TPC-H 渠道审计这些结果，两者都有机会进入 SF1,000 上 TPC-H 最高性能结果的前 3 名。
我们把 Vera 的性能优势归因于三个关键因素。第一，高内存带宽使扫描快速。第二，加上低内存延迟，它使核心在处理期间持续保持忙碌。最后，Olympus 核心的大缓存允许高效访问聚合和连接期间构建的哈希表。
我们期待继续这项基准测试，使用 DuckDB v2.0.0 的稳定构建、在完整的双路设置上运行，并纳入不同的基准测试。
转载自 CSDN-专业IT技术社区
