对启用了 Auto Tiering 的数据库进行基准测试
| Redis 企业软件 |
|---|
Redis Enterprise Software 上的 Auto Tiering 允许您使用经济高效的闪存作为数据库的 RAM 扩展。
但是，与仅存储在 RAM 中的纯内存数据库相比，性能如何？
这些场景使用memtier_benchmark实用程序来评估 Redis Enterprise Software 部署（包括试用版）的性能。
这memtier_benchmark实用程序位于/opt/redislabs/bin/的 Redis Enterprise Software 部署。要测试云提供商部署的性能，请参阅 memtier-benchmark GitHub 项目。
如需其他帮助，例如获得大型集群的帮助，请联系支持人员。
基准测试和性能测试注意事项
这些测试假定您使用的是 Redis Enterprise Software 的试用版，并且希望在以下情况下测试启用了 Auto Tiering 的数据库的性能：
- 无复制：四 （4） 个主分片
- 使用复制：两 （2） 个主分片和 2 个副本分片
使用 Redis Enterprise Software 的试用版，您可以使用数据库配置组合创建最多包含四个分片的集群，包括：
- 四个数据库，每个数据库都有一个主分片
- 两个启用了复制的高可用性数据库（每个数据库都有一个主分片和一个副本分片）
- 一个具有 4 个主分片的非复制集群数据库
- 一个高可用性集群数据库，具有两个主分片和两个副本分片
测试环境和集群设置
对于测试环境，您需要：
- 创建具有三个节点的集群。
- 准备闪存。
- 配置负载生成工具。
创建三节点集群
此性能测试需要一个三节点集群。
您可以使用以下主机在 Amazon AWS 上运行所有这些测试：
-
2 个 i3.2xlarge（8 个 vCPU，61 GiB RAM，高达 10GBit，1.9TB NMVe SSD）
这些节点提供 RoF 数据
-
1 个 m4.large，用作仲裁节点
要了解如何安装 Redis Enterprise Software 和设置集群，请参阅：
- 用于测试安装的 Redis Enterprise Software 快速入门
- 安装和升级 用于生产安装
这些测试使用仲裁节点来减少 AWS EC2 实例的使用，同时在节点发生故障时保持支持仲裁节点所需的三个节点。Quorum 节点可以位于功能较弱的实例上，因为它们没有分片或支持流量。
在撰写本文时，需要 i3.2xlarge 实例，因为它们支持 NVMe SSD，而 NVMe SSD 是支持 RoF 所必需的。Auto Tiering 需要支持闪存的存储，例如 NVMe SSD。
为获得最佳结果，请将启用 Flash 的部署的性能与纯 RAM 环境（例如严格的本地部署）中的性能进行比较。
准备闪存
在节点上安装 RS 后，
附加到 i3.2xlarge 实例的闪存必须使用/opt/redislabs/sbin/prepare_flash.sh脚本。
设置负荷生成工具
memtier_benchmark Load Generator 工具在 RoF 数据库上生成负载。 要使用此工具，请在不属于 RS 群集的专用实例上安装 RS 但位于集群的同一区域/区域/子网中。 我们建议您使用功能相对强大的实例，以避免负载生成工具本身出现瓶颈。
对于这些测试，负载生成主机使用 c4.8xlarge 实例类型。
数据库配置参数
创建 Auto Tiering 测试数据库
您可以使用 Redis Enterprise Cluster Manager UI 创建测试数据库。 我们建议您为具有以下要求的每个测试用例使用单独的数据库：
| 参数 | 使用复制 | 无复制 | 描述 |
|---|---|---|---|
| 名字 | 测试 1 | 测试 2 | 测试数据库的名称 |
| 内存限制 | 100 吉字节 | 100 吉字节 | 内存限制是指跨数据库的所有分片（包括主分片和副本分片）聚合的 RAM+Flash。 |
| RAM 限制 | 0.3 | 0.3 | RoF 始终将 Redis 键和 Redis 字典保存在 RAM 中，并且需要额外的 RAM 来存储热值。出于这些测试的目的，30% RAM 被计算为最佳值。 |
| 复制 | 启用 | 禁用 | 没有复制的数据库只有主分片。具有复制功能的数据库具有主分片和副本分片。 |
| 数据持久化 | 没有 | 没有 | 这些测试不需要数据持久性。 |
| 数据库集群 | 启用 | 启用 | 集群数据库由多个分片组成。 |
| （主）分片数 | 2 | 4 | 分片的分布方式如下： - 有复制：每个节点上 一个主分片和一个副本分片- 无复制：每个节点上有两个主分片 |
| 其他参数 | 违约 | 违约 | 保留其他配置参数的默认值。 |
数据填充
填充基准数据集
memtier_benchmark Load Generation 工具将填充数据库。 要使用 N 个大小为 500 字节的项目填充数据库，请在负载生成实例上运行：
$ memtier_benchmark -s $DB_HOST -p $DB_PORT --hide-histogram
--key-maximum=$N -n allkeys -d 500 --key-pattern=P:P --ratio=1:0
Set up a test database:
Parameter
Description
Database host
(-s)
The fully qualified name of the endpoint or the IP shown in the RS database configuration
Database port
(-p)
The endpoint port shown in your database configuration
Number of items
(–key-maximum)
With replication: 75 Million
Without replication: 150 Million
Item size
(-d)
500 Bytes
Centralize the keyspace
With replication
To create roughly 20.5 million items in RAM for your highly available clustered database with 75 million items, run:
$ memtier_benchmark -s $DB_HOST -p $DB_PORT --hide-histogram
--key-minimum=27250000 --key-maximum=47750000 -n allkeys
--key-pattern=P:P --ratio=0:1
To verify the database values, use Values in RAM metric, which is available from the Metrics tab of your database in the Cluster Manager UI.
Without replication
To create 41 million items in RAM without replication enabled and 150 million items, run:
$ memtier_benchmark -s $DB_HOST -p $DB_PORT --hide-histogram
--key-minimum=54500000 --key-maximum=95500000 -n allkeys
--key-pattern=P:P --ratio=0:1
Test runs
Generate load
With replication
We recommend that you do a dry run and double check the RAM Hit Ratio on the Metrics screen in the Cluster Manager UI before you write down the test results.
To test RoF with an 85% RAM Hit Ratio, run:
$ memtier_benchmark -s $DB_HOST -p $DB_PORT --pipeline=11 -c 20 -t 1
-d 500 --key-maximum=75000000 --key-pattern=G:G --key-stddev=5125000
--ratio=1:1 --distinct-client-seed --randomize --test-time=600
--run-count=1 --out-file=test.out
Without replication
Here is the command for 150 million items:
$ memtier_benchmark -s $DB_HOST -p $DB_PORT --pipeline=24 -c 20 -t 1
-d 500 --key-maximum=150000000 --key-pattern=G:G --key-stddev=10250000
--ratio=1:1 --distinct-client-seed --randomize --test-time=600
--run-count=1 --out-file=test.out
Where:
Parameter
Description
Access pattern (--key-pattern) and standard deviation (--key-stddev)
Controls the RAM Hit ratio after the centralization process is complete
Number of threads (-t and -c)\
Controls how many connections are opened to the database, whereby the number of connections is the number of threads multiplied by the number of connections per thread (-t) and number of clients per thread (-c)
Pipelining (--pipeline)\
Pipelining allows you to send multiple requests without waiting for each individual response (-t) and number of clients per thread (-c)
Read\write ratio (--ratio)\
A value of 1:1 means that you have the same number of write operations as read operations (-t) and number of clients per thread (-c)
Test results
Monitor the test results
You can either monitor the results in the Metrics tab of the Cluster Manager UI or with the memtier_benchmark output. However, be aware that:
-
The memtier_benchmark results include the network latency between the load generator instance and the cluster instances.
-
The metrics shown in the Cluster Manager UI do not include network latency.
Expected results
You should expect to see an average throughput of:
- Around 160,000 ops/sec when testing without replication (i.e. Four master shards)
- Around 115,000 ops/sec when testing with enabled replication (i.e. 2 master and 2 replica shards)
In both cases, the average latency should be below one millisecond.
On this page