进行 Graviton2 R6g 缓存实例测试前环境的准备

1. 前言
从2020年10月开始，基于 Amazon Graviton2 的缓存实例逐步推出，客户可以在使用 Amazon ElastiCache for Redis 上使用这些实例。
Graviton2 处理器由 Amazon Web Services 使用 64 位 ARM Neoverse 内核定制，对第一代 Amazon Graviton 处理器进行了多种性能优化。这包括 7 倍的性能、4 倍的计算核心数量、每个内核 2 倍的私有内存、5 倍的内存速度和每个核心 2 倍的浮点性能。此外，Graviton2 处理器还具有全天候运行的全加密 DDR4 内存功能，且每核加密性能提高 50%。这些性能提升使得装备了Graviton2 的实例成为缓存工作负载的上佳之选。

本文将向您展示 Graviton2 R6g 缓存实例（测试实例类型 cache.r6g，后续简称 r6g 或 R6g）对R5缓存实例（cache.r5，后续简称 r5 或 R5）的性能增强以及迁移到Graviton2 R6g 缓存实例的方法流程。

通过测试我们可以清楚地看到，无论是何种工作负载和并发条件，R6g实例比之同等资源配置的 R5 实例性能均有显著的提升，而且每小时单价却有下降，在这双重因素的叠加之下，选择新一代的 r6g 实例，具有更好的性能和性价比。
 

2.1 环境信息

测试客户端（新加坡区域，AZ3）

表格：测试客户端配置

测试服务端（新加坡区域，主用在 AZ3）

表格：测试服务端配置

ElastiCache for Redis 选择默认参数，开启了集群模式（Cluster），数据用3个分片（每个分片1主2从，合计9个节点，为了系统的高可用和管理需要，默认参数会设置25%的内存作为预留内存，所以读者在自己做性能测试时要留意别把内存耗光导致结果失真，这也是我们没有选择最低配置的实例做测试的原因之一）。

部署完毕后的集群地址：

我们把测试客户端和集群的主节点人工强行放到了同一个AZ以获取更直接的对比效果，同时选用的 ElastiCache for Redis 集群实例（3*3的 2xlarge 构建的集群）和测试客户端（8xlarge 的 EC2）均支持 10G 的带宽模式，读者在自己做测试时也要避免因网络带宽不足导致的测试结果失真。

可能很多读者会问，为什么测试的时候只选择这一个机型？细心的读者可能会发现，亚马逊云的机型是有一定规律的，例如 4xlarge 的配置刚好是 2xlarge 的两倍，而 8xlarge 的又刚好是 4xlarge 的两倍（以此类推，具体机型定义请参看 这里），所以此处我们用 r5.2xlarge 和 r6g.2xlarge 做个具有代表性的对比测试，就不用其他机型一一对比了。

 

此处我们使用两个不同的压测工具做针对性测试，一个是 Redis 自带的简单易用的 redis-benchmark，一个是 Redis Labs 开源提供的在更高并发的场景使用的 memtier_benchmark。

2.2.1 redis-benchmark

redis-benchmark 默认含在 redis 的分发里面，直接安装 redis 即可获得，在 Amazon Linux 2 操作系统上使用如下命令即可（这个安装在客户端上，后续迁移的时候也会用到这个客户端源）。

amazon-linux-extras install redis4.0 -y

 

表格：redis-benchmark 的常用参数

2.2.2 memtier_benchmark

memtier_benchmark 需要使用 github 上的源码进行编译才能使用，在 Amazon Linux 2 操作系统上可以使用如下方式：

其命令的常用参数选项如下：

表格：memtier_benchmark 的常用参数

相关文章

返回上一级 弹性计算文章 >>