Vertica 数据库硬件配置指南¶
2026-06-13 更新：版本生命周期更新至 26.2.x；CPU 建议去除已停产型号，增加 AMD EPYC / ARM 说明；存储新增 NVMe SSD 推荐（原 SAS HDD 建议降级为低预算选项）；新增 2.5 Eon 模式专属硬件考量（Depot 规划、公共存储选型、分片/节点配比、子集群）；OS 从 RHEL 7.x 更新至 RHEL 8.x/9.x 及更多发行版；文档链接更新至 26.2.x。
Vertica 分析平台软件在对等节点的无共享 MPP 集群上运行。集群的每个节点是独立的，无主节点、无控制节点。企业部署模式下，数据根据分布键分散存储在所有计算节点上，所有节点并行参与计算。Eon部署模式下，数据持久存储在共享存储上，本地作为高速缓存，将所有的热数据存放在计算节点本地。
本文提供了选择和配置单个物理服务器作为 Vertica 节点的建议。主要内容来源于官方文档（原文发布于 2024 年 7 月 3 日），更新至 Vertica 26.2.x。版本生命周期详情见 Product Support Lifecycle。
1. 推荐软件¶
OpenText（原 Micro Focus）为 Vertica 的每个主要版本提供约 3 年的技术支持。如果使用的版本研发不再支持，当遇到不能确定的 bug 时，无法提 case 到研发进一步排查、修复。
可通过官方 OpenText 产品支持生命周期查询当前在保的版本号以及计划过保时间，也可参照官方的这个时间表规划自己系统的版本升级计划。
注意：截至 2026 年 6 月，当前最新版本为 Vertica 26.2.x。以下列出当前在保的主要版本：
| 版本号 | 状态 | 计划过保日期 |
|---|---|---|
| Vertica 26.2.x | 在保 | 30 Apr 2029 |
| Vertica 26.1.x | 在保 | 28 Feb 2029 |
| Vertica 25.4.x | 在保 | 31 Oct 2028 |
| Vertica 25.3.x | 在保 | 31 Jul 2028 |
| Vertica 25.2.x | 在保 | 30 Apr 2028 |
| Vertica 25.1.x | 在保 | 31 Jan 2028 |
| Vertica 24.4.x | 在保 | 31 Oct 2027 |
| Vertica 24.3.x | 在保 | 31 Jul 2027 |
| Vertica 24.2.x | 在保 | 30 Apr 2027 |
| Vertica 24.1.x | 在保 | 31 Jan 2027 |
| Vertica 23.4.x | 在保 | 31 Oct 2026 |
| Vertica 23.3.x | 在保 | 31 Jul 2026 |
一般生产环境推荐使用次新大版本（如当前最新为 26.2，则推荐使用 26.1）的最新 hotfix 版，测试环境可以使用最新大版本（如 26.2.x）。具体每个版本支持的软件平台可以查看对应版本文档的 Supported Platforms 部分。
Vertica 26.2.x Supported Platforms
2. 选择服务器型号¶
通过官方的测试和大量客户的实践，单台 Vertica 节点的服务器配置建议如下：
| 项目 | 最低配置 | 推荐配置 |
|---|---|---|
| CPU | 双路, ≥2.6 GHz, ≥24 核 | 双路, ≥3.0 GHz, 32~64 核 |
| 内存 | 256 GB | 384~512 GB |
| 系统盘 | 2× SSD RAID1 | 2× NVMe SSD RAID1 |
| 数据盘（Enterprise 模式） | 10× SAS HDD / 4× NVMe SSD | 10× NVMe SSD RAID10 |
| 数据盘（Eon 模式 Depot） | 2× NVMe SSD | 4~10× NVMe SSD RAID10 |
| 网络 | 2× 10 GbE | 2× 25 GbE 或更高 |
核心理念：优先选择更高主频而非更多核心。Vertica 部分操作为单线程，主频直接影响响应时间；多核则提升并发处理能力。
2.1 处理器¶
Vertica 建议基于 Intel Xeon 或 AMD EPYC 处理器（x86_64 架构）为集群提供最佳性能。ARM（AArch64）架构自 24.1 起也已支持，但生产环境仍建议优先选择 x86_64。
选择 CPU 的关键原则：
- 主频优先：更高时钟速度直接提升 Vertica 数据库响应时间。选择 ≥2.6 GHz，推荐 ≥3.0 GHz。
- 核数适度：每路 CPU 16~32 个物理核心为当前最佳平衡点。过多核心可能导致单核性能下降。
- 同构集群：所有节点的 CPU 型号、主频、核数必须完全一致。
已过时的参考：原文档推荐的 Intel Xeon Gold 6246（Cascade Lake, 12核）和 Platinum 8268 已停产。当前应选择第四代/第五代 Xeon Scalable（Sapphire Rapids / Emerald Rapids）或 AMD EPYC 9004/9005 系列。
根据单个工作负载选择在 CPU 上启用超线程。超线程通过允许每个内核同时处理 2 个线程来增加每个 CPU 的逻辑内核数量。这对于短而快的进程可能非常有效，但对长时间运行的进程不利，因为单个进程可能导致第二个进程线程等待。
2.2 内存¶
为获得最佳性能，Vertica 每个计算节点应包括至少 256 GB 的 RAM。推荐配置是服务器中的每个物理核心有 8-12 GB 的 RAM。重度分析/ML 工作负载建议 512 GB 或更高。
当前应选择 DDR5 内存（如平台支持），将 DIMM 均匀分布到所有内存通道以最大化带宽。避免因仅填充部分通道而导致内存降速——Vertica 对内存带宽敏感。
2.3 存储¶
Vertica 工作负载的特点是大块随机 I/O，对存储吞吐量要求极高。随着 NVMe SSD 成本的持续下降，NVMe SSD 已成为 Vertica 部署的推荐标准存储介质。
存储介质对比¶
| 存储类型 | 单盘读写速度 | 适用场景 |
|---|---|---|
| NVMe SSD（PCIe 4.0/5.0） | 3,500~7,000 MB/s | ⭐ 首选，生产环境推荐 |
| SAS SSD | 500~1,000 MB/s | 预算有限的过渡方案 |
| SAS HDD 10K/15K RPM | 150~250 MB/s | ⚠️ 仅限低负载/历史遗留 |
注意：原文档中"SAS 盘至少 10 块（推荐 20 块以上）"的建议是针对机械硬盘时代的。使用 NVMe SSD 时，4~10 块盘即可满足绝大多数工作负载的 I/O 需求。
NVMe SSD 配置建议¶
Enterprise 模式（数据盘）：
- 10× 1.6 TB NVMe SSD，RAID 10 → 约 8 TB 格式化容量/节点
- 或 10× 3.2 TB NVMe SSD，RAID 10 → 约 16 TB 格式化容量/节点
- 每个存储位置最大 16 TB，最多可配置 2 个存储位置（合计 32 TB）
Eon 模式（Depot 缓存）：
- 4~10× NVMe SSD，RAID 10 → 4~8 TB 格式化容量
- Depot 大小应根据热数据量确定，通常数据盘的 30%~50%
系统盘（OS + Catalog）：
- 2× 480 GB~960 GB SSD/NVMe，RAID 1
如果仍然使用 SAS HDD（仅限低预算或低负载场景），至少 10 块（推荐 20 块以上）组成阵列。使用转速为 10K 或更高的企业级 12 Gb/s SAS 驱动器。
磁盘阵列控制器（SAS HDD 场景）¶
如果使用 SAS HDD，部署一个磁盘阵列控制器：
- 支持至少四 (4) 个 12 Gb/s SAS 通道
- 至少有 1 GB 的配置缓存
- 可支持 RAID 1、RAID 5、RAID 10 或 RAID 50
使用 NVMe SSD 时无需 RAID 控制器——NVMe 直接通过 PCIe 总线与 CPU 通信，软件 RAID（mdadm）或 LVM 即可。
Vertica 安装至少需要两个存储位置——一个用于操作系统和目录，另一个用于数据。将这些数据位置放在专用的连续存储卷上。
Vertica 是一个多线程应用程序。Vertica 数据位置 I/O 配置文件的最佳特征是大块随机 I/O。
Vertica可以使用以下这些存储类型：本地存储、SAN阵列、NAS存储单元、DAS存储。在每种情况下，存储对于主机来说都是一个文件系统，应该能够提供足够的 I/O 带宽。使用本地 NVMe SSD 组成 RAID 以最低的 TCO 提供最佳的性价比。如果考虑采用SAN或者NAS存储，请务必保证计算节点与存储之间的负载均衡以及I/O带宽，避免存储访问成为系统的瓶颈。
您可以使用数据库自带的vioperf工具来测试I/O吞吐量，以了解基准I/O性能。
所需的最低 I/O 是每个节点上每个物理处理器内核最低 20 MB/s 读写，建议每个物理内核的读写速度为 40 MB/s 或更高。该值基于在集群的所有节点上同时以全双工运行并以该速率同时读写。
2.3.1 数据盘 RAID 配置¶
NVMe SSD 场景（推荐）：
- 使用 Linux mdadm 创建软件 RAID 10，条带大小 512 KB~1024 KB
- 或使用 LVM 创建条带化逻辑卷，条带大小 2048 KB
- 无需 RAID 控制器缓存设置（NVMe 直接 PCIe 通信）
SAS HDD 场景（传统）：
- 将所有数据盘配置为一个 RAID 10 设备，默认条带大小为 512 KB（RAID方式可优化设置为1024KB，LVM方式可设置为2048KB）
- 如果愿意牺牲一些磁盘性能来增加存储空间并提供更多冗余，可以选择 RAID 5 或 RAID 50
- RAID控制器缓存比率设置应该有利于写入而不是读取（10/90，如果可用）
逻辑驱动器（LVM）应使用跨越整个驱动器的单个主分区进行分区。
将 Vertica 的 data 存储位置放在单独的物理存储卷上。不要将 Vertica 的 data 与 catalog 位置放在同一存储位置。Vertica 的 catalog 位置应与操作系统驱动器位于同一位置，或配置在其他驱动器上。
笔者注：一般情况下数据库的catalog与data目录都放在挂载的数据存储路径即可，通常是
/data/目录。
有关详细信息，请阅读官方文档中的Installing Vertica。
注：Vertica 仅支持在 LVM 2.02.66 或更高版本的 I/O 路径中配置了 Linux 逻辑卷管理器的存储，并且必须包含 1.02.48 或更高版本的设备映射器。此限制适用于所有 Vertica 存储位置，包括通常位于操作系统驱动器上的目录。
2.3.2 Linux I/O 调优¶
为了支持 Vertica 节点上的最大性能，Vertica 建议为 Vertica 数据位置卷使用以下 Linux I/O 配置设置：
- 推荐的 Linux 文件系统是 ext4（也可使用 xfs）。
- NVMe SSD：推荐使用
none（noop）I/O 调度器，因为 NVMe 设备内部已高度并行。 - SAS/SATA：推荐使用
mq-deadline（较新内核）或deadlineI/O 调度器。 - 推荐的 Linux readahead设置为 8192 个 512 字节扇区 (4 MB)。
操作系统管理员应持久配置 Vertica 数据卷的 I/O scheduler 和 readahead 设置，以便这些设置在服务器重新启动时保持不变。
2.3.3 数据 RAID 配置示例¶
注意：以下步骤仅作为示例提供，可能不适合您的机器。在运行这些命令之前，请验证您的机器的驱动器号和数量。
- 对 RAID 10 数据驱动器进行分区和格式化：
- 创建
/data挂载点，在/etc/fstab文件中添加一行，然后挂载 Vertica 数据卷：
- 为了使 Linux I/O scheduler、Linux Readahead和大页面碎片整理设置在系统重新启动时保持不变，可使用 udev 规则或 systemd service。以下为参考命令（以 NVMe 设备为例）：
# 对 NVMe 设备使用 none 调度器
echo none > /sys/block/nvme0n1/queue/scheduler
blockdev --setra 8192 /dev/nvme0n1
# 禁用透明大页面以提高性能
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo no > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
# SAS/SATA 设备
echo mq-deadline > /sys/block/sda/queue/scheduler
blockdev --setra 2048 /dev/sda
推荐：使用 udev 规则（
/etc/udev/rules.d/）或 systemd service 持久化以上设置，而非依赖/etc/rc.local（RHEL 8+ 已默认不启用 rc-local）。
- 配置存储后，运行 vioperf 以了解基准 I/O 性能。
以下测试数据是 Vertica 节点 I/O 性能的理想参考目标：
- NVMe SSD：读写 3,000+ MB/s，rewrite 1,500+ MB/s
- SAS HDD 15K RPM（≥20 盘）：读写 2,200 MB/s
- SAS HDD 10K RPM（≥20 盘）：写入 2,200 MB/s，读取 1,500 MB/s
- rewrite 800+ MB/s（HDD），7k+ seeks/s
如果您的测试结果明显偏低，请查看前面的步骤以验证您是否正确配置了数据存储位置。
2.4 网络¶
为支持最大性能的 MPP 集群操作，Vertica 节点应包括至少两个 10 Gb 以太网端口（推荐 25 GbE 或更高），bond在一起以实现性能和冗余。对于单节点数据量超过 32 TB 的高密度配置，建议使用 25 GbE 或 100 GbE 以加速节点恢复。
Vertica 集群由 Vertica 节点、关联的网络交换机和 Vertica 软件组成。
Vertica 建议您考虑将 Vertica 节点连接到两个单独的网络平面：
- 专用/私有/心跳网络（例如集群互连）专门用于内部集群通信。此网络必须是相同的子网、专用交换机或 VLAN、10 Gb 以太网（或更高）。Vertica 在此网络上执行 TCP P2P 通信和 UDP 广播。必须静态分配专用网络接口的 IP 地址。不允许通过专用集群网络进行外部流量。
- 公共/业务网络用于数据库客户端（即应用程序）连接，它应该是 10 Gb 以太网（或更高）。Vertica 对公网配置没有硬性要求。但是，Vertica 建议您为公共网络接口分配静态 IP 地址。
私有网络平面应具有以太网冗余。否则，互连（特别是交换机）将成为集群范围内的单点故障。
即使在公共网络完全失效的情况下，集群操作也不受影响。因此，公共网络冗余在技术上不是必需的。但是，如果发生故障，应用程序与数据库的连接会受到影响。因此，请考虑公共网络冗余以实现整个环境的持续可用性。
要在专用网络和公共网络上实现冗余：
- Take the two ports from the Ethernet card on the server and run one to each of the two top-of-rack switches (which are bonded together in an IRF).
- Bond the links together using LACP.
- Using VLANs, divide the links into public and private networks.
2.4.1 配置网络¶
下图说明了实现高吞吐量和高可用性的典型网络设置（此图仅用于演示目的）。此图显示适配器的绑定允许一个适配器发生故障，而连接不会失败。这种绑定提供了网络端口的高可用性。绑定适配器也使吞吐量翻倍。
此外，这种配置允许关于交换机的高可用性。如果交换机发生故障，集群不会关闭。但是，它可能会降低 50% 的网络吞吐量。
2.4.2 优化 TCP/IP 堆栈¶
根据您的工作负载、连接数和客户端连接速率，调整 Linux TCP/IP 堆栈以提供足够的网络性能和吞吐量。
以下脚本代表 Vertica 集群的推荐网络 (TCP/IP) 调整参数。其他网络特性可能会影响这些参数优化您的吞吐量的程度。
将以下参数添加到 /etc/sysctl.conf 文件（或 /etc/sysctl.d/ 目录下的独立配置文件）。更改将在下次重新启动后生效。
# Increase number of incoming connections
net.core.somaxconn = 1024
#Sets the send socket buffer maximum size in bytes.
net.core.wmem_max = 16777216
#Sets the receive socket buffer maximum size in bytes.
net.core.rmem_max = 16777216
#Sets the receive socket buffer default size in bytes.
net.core.wmem_default = 262144
#Sets the receive socket buffer maximum size in bytes.
net.core.rmem_default = 262144
#Sets the maximum number of packets allowed to queue when a particular interface receives packets faster than the kernel can process them.
# increase the length of the processor input queue
net.core.netdev_max_backlog = 2000
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_wmem = 8192 262144 8388608
net.ipv4.tcp_rmem = 8192 262144 8388608
net.ipv4.udp_mem = 16777216 16777216 16777216
net.ipv4.udp_rmem_min = 16384
net.ipv4.udp_wmem_min = 16384
如果您有高并发工作负载并且 Vertica 设置了 CPU bound，则可以使用以下命令增加队列的内存和队列深度：
2.5 Eon 模式专属硬件考量¶
Eon 模式的核心区别在于计算与存储分离：数据持久存储于共享的公共存储（Communal Storage），计算节点本地仅保留热数据缓存（Depot）。这使得硬件的侧重点与传统 Enterprise 模式有所不同。
2.5.1 节点角色变化¶
| 维度 | Enterprise 模式 | Eon 模式 |
|---|---|---|
| 数据持久层 | 本地磁盘 | 公共存储（S3/MinIO/HDFS 等） |
| 节点存储 | 全量数据副本 | 仅 Depot 缓存 + Catalog |
| 扩缩容 | 需数据重分布（rebalance） | 弹性：增减节点无需搬数据 |
| 最小节点数 | 3（K-safe=1） | 3（K-safe=1） |
| CPU/内存要求 | — | 基本一致，但可更灵活 |
Eon 模式下 CPU 和内存的选型原则与 Enterprise 模式相同（见 2.1、2.2 节），但由于数据在公共存储，单节点存储需求大幅降低。
2.5.2 Depot 容量规划¶
Depot 是 Eon 节点本地磁盘上用于缓存热数据的区域，直接决定查询性能。如果 Depot 无法容纳工作数据集，将频繁从公共存储拉取数据，性能严重下降。
60/40 分配规则：
| 用途 | 占比 | 说明 |
|---|---|---|
| Depot（数据缓存） | 60% | 缓存热数据，承载数据加载缓冲 |
| Catalog + 临时数据 | 40% | 元数据 + 排序溢出 + 临时表 |
Depot 大小公式：
即 Depot 应至少能容纳该节点订阅分片所对应的全部压缩数据。建议在此基础上预留 20%~30% 余量应对数据增长。
示例：24 TB 压缩工作数据，3 节点 → Depot 需 ≥ 24 / 3 = 8 TB/节点 → 本地盘需 ≥ 8 / 0.6 ≈ 13 TB/节点。
实践经验：
- 小型集群（≤24TB 数据）：Depot 4~8 TB/节点，本地盘 8~16 TB
- 中型集群（≤48TB 数据）：Depot 8~16 TB/节点，本地盘 16~32 TB
- 如果单次数据加载量超过所有节点 Depot 总和，应增大 Depot 容量而非绕过缓存——直写公共存储会导致后续查询被迫从远端拉取数据，性能严重下降
2.5.3 公共存储（Communal Storage）选型¶
| 方案 | 适用场景 | 备注 |
|---|---|---|
| AWS S3 | 云端部署 | 原生支持 |
| MinIO | 本地/私有云 | 须使用分布式模式（生产环境） |
| Pure Storage FlashBlade | 本地高性能 | S3 协议，36 GB/s 吞吐，~150µs 延迟 |
| HPE Alletra Storage MP X10000 | 本地 | S3 协议 |
| HDFS（WebHDFS） | 已有 Hadoop 生态 | 必须使用 WebHDFS 服务（webhdfs:// 或 swebhdfs://），不兼容 HttpFS。不兼容 Cloudera 5.x 和 MapR（MapR 走 NFS 挂载）。 其余支持 WebHDFS 的发行版均可。 详见 Eon On-Premises Storage |
公共存储带宽要求：
- 数据加载 + Depot fetch 峰值决定了所需带宽
- 参考实际测算：数据加载峰值 + Depot fetch 峰值 ≈ 54 Gbps（平时），月初冲高 3 倍 ≈ 162 Gbps
- 公共存储侧网络带宽与集群内部互联同等重要，避免存储访问成为瓶颈
2.5.4 分片（Shard）与节点配比¶
分片数决定了查询的最大并行度。在 Eon 模式下，分片数在创建数据库时设定（12.0+ 支持 RESHARD_DATABASE 在线调整）。
| 规则 | 说明 |
|---|---|
| 最优配比 | 分片数 : 节点数 = 1:1 |
| 推荐上限 | ≤ 2:1 |
| 绝对上限 | ≤ 3:1（管理控制台会告警） |
| 可整除 | 分片数应为节点数的约数或倍数，避免热点 |
集群规模参考：
| 规模 | 工作数据量 | 推荐初始节点数 | 推荐分片数 |
|---|---|---|---|
| 小型 | ≤ 24 TB | 3 | 3~6 |
| 中型 | ≤ 48 TB | 6 | 6~12 |
| 大型 | ≤ 96 TB | 12 | 12~24 |
| 超大型 | ≤ 192 TB | 24 | 24~48 |
选择具有更多约数的分片数（如 6、8、12、24）以便未来灵活扩展。
2.5.5 子集群（Subcluster）与工作负载隔离¶
Eon 模式支持创建多个子集群，为不同工作负载提供硬件隔离：
| 子集群类型 | 用途 | 硬件侧重 |
|---|---|---|
| Primary | 数据写入、ETL | 充足的 Depot（承接写入缓冲）；较高 CPU |
| Secondary | 只读查询 | Depot 可较小（仅缓存查询热数据）；侧重 CPU/内存 |
| Sandbox | 测试/开发 | 最小规格即可 |
关键原则：
- 每个子集群独立订阅所有分片，因此子集群数量增加会线性增加公共存储访问压力
- 网络隔离：不同子集群可部署在不同 VLAN/网段，互不影响
2.5.6 Eon 节点硬件速查¶
| 项目 | 最低配置 | 推荐配置（中型集群） |
|---|---|---|
| CPU | 双路, ≥2.6 GHz, ≥16 核 | 双路, ≥3.0 GHz, 32~64 核 |
| 内存 | 128 GB | 256~512 GB |
| 系统盘 | 2× SSD RAID1 | 2× NVMe SSD RAID1 |
| Depot（数据缓存） | 2 TB NVMe SSD | 8~16 TB NVMe SSD（RAID 10） |
| Catalog + 临时 | 与系统盘共用或独立 SSD | 占本地盘 40% |
| 网络（集群互联） | 2× 10 GbE | 2× 25 GbE |
| 网络（到公共存储） | 10 GbE | 25 GbE 或更高 |
Eon 模式节点的 CPU/内存要求与 Enterprise 模式相当（计算负载未减少），但本地存储需求显著降低——不需要存全量数据，只需存热数据缓存。
3. 附加 (BIOS) 设置¶
当硬件针对高性能、低延迟的应用程序进行调整时，Vertica 的性能最佳。基于 Intel 或 AMD 的处理器提供了广泛的节能技术。这些技术可以降低服务器的整体功耗，但也会影响高端性能。
要获得最佳性能，请按照硬件制造商的指南在 Vertica 节点的 BIOS 中禁用 CPU 扩展和省电功能。许多硬件供应商提供文档化指南，用于针对高性能、低延迟的应用程序（如 Vertica）调整其特定服务器。
关键 BIOS 设置：
- Power Profile：设置为 Maximum Performance
- C-States：禁用（或限制为 C0/C1）
- P-States：禁用或设为 Maximum Performance
- 超线程：根据工作负载评估（短查询有利，长查询不利）
- NUMA：保持启用（Vertica 能感知 NUMA 拓扑）
此外，您必须在内核启动参数中禁用 CPU C-states 和 CPU 频率调节驱动。对于 RHEL 8.x/9.x（或 Rocky Linux 8/9），使用 grubby 修改内核参数：
Intel CPU：
# grubby --update-kernel=ALL --args="intel_idle.max_cstate=0 processor.max_cstate=1 intel_pstate=disable"
AMD EPYC CPU：
或手动编辑 /etc/default/grub 并在 GRUB_CMDLINE_LINUX 行追加参数后执行 grub2-mkconfig。
注意：原文档推荐 RHEL 7.x，该版本已于 2024 年 6 月 30 日 EOL。当前生产环境应使用 RHEL 8.x 或 RHEL 9.x。Vertica 26.2.x 支持的操作系统包括：RHEL 8.x/9.x、Rocky Linux 8.x/9.x、SLES 15 SP4+、openSUSE Leap 15.4+、Oracle Enterprise Linux 9.x（Red Hat 兼容内核）、Debian 12.x/13.x、Ubuntu 20.04 LTS+、Amazon Linux 2023。支持 x86_64 和 AArch64 架构。
4. Vertica 验证实用程序¶
每个 Vertica 安装都包含一组验证实用程序，通常位于 /opt/vertica/bin 目录中。如前所述，这些工具可以帮助您确定 Vertica 节点和集群的整体性能。
- 使用
vcpuperf测量 CPU 处理速度，对比基准 CPU 数据检测是否启用 CPU 节流。 - 使用
vioperf测试 I/O 子系统性能（顺序写/重写/读/跳读），识别 I/O 瓶颈。 - 使用
vnetperf测量节点间 TCP/UDP 延迟和吞吐量，诊断网络问题。
三个工具均位于 /opt/vertica/bin，详见 Validation Scripts。
Vertica 建议您在初始部署期间使用这些工具，同时定期运行这些实用程序以确定性能是否随时间变化。这使您可以确定是否有任何系统更改对 Vertica 性能产生不利影响。
扩展阅读¶
- Vertica 集群网络性能优化与诊断最佳实践 — 网络性能诊断与优化完整路径
- Vertica Spread 配置最佳实践 — 大型集群 Spread Segment 配置建议
- Vertica Linux IO 调度器性能影响与调优 — 磁盘 I/O 调度器对数据库性能的影响
- Projection 优化最佳实践 — 存储布局优化与硬件选型的协同考虑