采用 XIRAID 引擎和 Kioxia PCIe5 驱动器的虚拟环境中 PostgreSQL 的高性能存储解决方案
目标
PostgreSQL 是一款非常流行的开源数据库，因其功能丰富、性能稳健、数据处理灵活而广受青睐。它被广泛应用于从小型网站到大型企业级应用的各种场景，其对象关系型特性、高级索引支持以及强大的安全性吸引了大量用户。然而，要真正发挥其潜力，PostgreSQL 对存储系统提出了很高的要求：事务性操作和大规模数据集的处理需要低延迟和高吞吐量。因此，将 PostgreSQL 搭配高速存储方案是优化性能、减少停机时间并确保在高负载下流畅访问数据的关键。
为了提升灵活性、可扩展性和成本效率，通常更倾向于在虚拟机（VM）上运行 PostgreSQL，尤其是在开发和测试环境中。但有时，虚拟化会引入一层抽象层，从而带来一定的性能开销，相较于裸金属环境可能会有所下降。另一方面，仅使用裸金属服务器则可能导致 CPU 和存储资源利用率低下，因为单一应用程序往往无法完全利用裸金属服务器的全部性能。
本文将探讨如何在虚拟化环境中为 PostgreSQL 提供最优性能。
为此，我们将对比 vHOST 内核目标 + Mdadm 与 SPDK vhost-blk 目标（受 Xinnor 的 xiRAID Opus 保护）的性能表现。
Mdadm（“Multiple Devices Administration”的缩写）是一款 Linux 系统中的软件工具，用于管理软件 RAID（独立磁盘冗余阵列）配置。与硬件 RAID 控制器不同，mdadm 依赖于计算机的 CPU 和软件来实现跨多个物理磁盘的数据冗余和性能提升。
XiRAID Opus（Optimized Performance in User Space，用户空间优化性能）是一款基于 SPDK 库的高性能软件 RAID 引擎，专为 NVMe 存储设备设计。
我们专注于软件 RAID 的基准测试，因为硬件 RAID 控制器最多只支持 16 条 PCIe 通道，这意味着其性能上限只能达到最多 4 块 NVMe 驱动的性能总和，这显然不足以满足 PostgreSQL 应用的需求。
我们使用的测试工具是 pgbench，并对所有三种内置脚本进行了测试：tpcb-like、simple-update 和 select-only。脚本细节详见附录 2。
测试设置
硬件配置：
主板 ：Supermicro H13DSH
CPU ：双 AMD EPYC 9534 64 核处理器
内存 ：773,672 MB
驱动器 ：10 x KIOXIA KCMYXVUG3T20
软件配置：
操作系统 ：Ubuntu 22.04.3 LTS
内核版本 ：5.15.0-91-generic
xiRAID Opus 版本 ：xnr-1077
QEMU 模拟器版本 ：6.2.0
RAID 配置：
创建了两个 RAID 组（4+1 配置），使用分布在两个独立 NUMA 节点上的驱动器。条带大小设置为 64KB，并在基准测试前完成了完整的 RAID 初始化。
每个 RAID 组被划分为 7 个段，每个段通过专用的 vhost 控制器分配给一个虚拟机。
资源分配概览：
RAID 组 ：2 个
卷 ：14 个
vhost 控制器 ：14 个
虚拟机 ：14 台，每台使用分段的 RAID 卷作为存储设备。
在创建 mdraid、卷和 vhost 目标的过程中，由于不支持指定 CPU 核心绑定，未进行特定核心的分配。不过，虚拟机仍在特定的核心上运行。
使用 xiRAID，可以将 RAID 引擎绑定到特定的核心。在此示例中，我们在每个 NUMA 节点上使用了 8 个核心。这种布局可以实现基础设施与数据库工作负载的分离，同时做到虚拟机之间的负载隔离。
而 MDRAID 并不具备这一功能，因此应用程序必须与 RAID 引擎共享核心资源。
虚拟机配置
CPU 分配：8 核
命令参数：-cpu host -smp 8
QEMU 内存配置：
内存分配：每台虚拟机通过 Hugepages 分配 32GB RAM。内存预分配并绑定到与 vCPU 同一 NUMA 节点，以确保高效的 CPU-内存交互。
命令行参数：
操作系统：虚拟机运行 Debian GNU/Linux 12（Bookworm）
PostgreSQL 版本：15
PostgreSQL 配置：
数据目录配置：
我们创建并初始化了一个用于测试的数据库。选择合适的缩放比例很重要，这样所有数据不会完全加载进内存。
测试过程
我们在客户端数量变化的情况下进行了测试，仅在本文中报告了达到最大稳定结果的数据。为了调整客户端数量，我们为参数 -c（模拟的客户端数量，等于并发数据库会话数）选择了以下数值：10、20、50、100、200、500、1000。对于所有脚本类型，我们在 100 客户端时达到了性能峰值。
按照最佳实践，我们将参数 -j（pgbench 内部线程数）设置为与虚拟机核心数相同。
说明：在多 CPU 机器上使用多个线程是有帮助的，客户端将尽可能均匀地分布在可用线程之间。
测试命令如下所示：
我们对每次测试执行了三次，并记录了所有虚拟机上的平均结果。此外，我们还在降级模式下进行了仅查询（select-only）测试，因为该脚本会对读取操作产生最大负载，从而可以评估其对数据库性能的最大影响。
在测试过程中，我们使用 iostat 工具监控阵列性能。整个服务器的性能是所有虚拟机性能的总和（xiRAID Opus 使用 14 台虚拟机，mdraid 使用 16 台）。
Select-only 测试结果
Select-only 测试结果 （降级模式）
简单更新测试结果
TPC-B 类似测试结果
结论
在仅查询（select-only）测试中，当所有 RAID 驱动正常运行时，xiRAID Opus 的每秒事务处理能力比 mdraid 高出 30%-40%。此时 mdraid 已接近其性能极限，进一步通过增加虚拟机核心数进行扩展将变得困难，而 xiRAID 则没有这个问题。主要原因是 xiRAID Opus 允许 vhost 目标在单独的 CCD 上运行。
在比较不同的保护机制时，不能仅关注正常运行下的性能。毕竟 RAID 的存在是为了防止一个或多个驱动器故障导致数据丢失。在这种情况下（降级模式），保持高性能至关重要，以避免数据库用户的停机。
在降级模式下比较性能时，mdraid 的性能大幅下降，比 xiRAID 慢了超过 20 倍。换句话说，在使用 MDRAID 时，用户将不得不等待数据返回，这种情况可能导致业务损失（比如在线旅行社或交易公司）。
当涉及向数据库写入数据时，每个小块写入都会引发 RAID 计算。在这种情况下，mdraid 的性能比 xiRAID Opus 差六倍。
TPC-B 类似的脚本比简单的更新更复杂，消耗更多的 CPU 资源，这再次拖慢了 mdraid 的写入操作。在这种情况下，xiRAID 的性能是 mdraid 的五倍。
总体而言，xiRAID 能够为多个虚拟机提供稳定且高性能的存储服务。
这意味着即使在驱动器故障或大量写入操作的情况下，应用程序也能无延迟地访问数据。此外，xiRAID 在虚拟机上的可扩展性使得系统管理员能够整合部署大型/多个数据库所需的服务器数量，简化了存储架构并带来了显著的成本节约。
您可以在此处查看原始博客文章：点击此处
版权声明: 本文为 InfoQ 作者【Sergey Platonov】的原创文章。
原文链接:【http://xie.infoq.cn/article/5ae8319c469a5325161e04661】。
本文遵守【CC-BY 4.0】协议，转载请保留原文出处及本版权声明。
还未添加个人签名 2025-03-18 加入
还未添加个人简介
评论