使用 Redis 对新推出的 AWS M3 实例进行基准测试

两周前，亚马逊推出了其新一代标准实例 (M3 实例)，在提供与 M1 实例相同平衡的 CPU 和内存资源的同时，将计算能力/核心增加了一倍。我们不会在我们的 Redis Cloud 集群中使用 M1 实例（它们无法满足 Redis 的高吞吐量、低延迟要求，详细内容请参阅此处），但想知道 M3 double extra-large 实例 (m3.2xlarge) 是否比我们在我们集群节点中使用的 m2.2xlarge high memory 实例的性能更好。这两个实例都具有相似的内存配置并使用相同类型的 vcore，因此使我们最感兴趣的是 M3 实例能够在 Xen 硬件虚拟化模式 (HVM) 中运行这一事实。所以，它们应该克服显著影响 Redis 性能的 Xen fork 时间问题（如此处中详细描述的）。此外，m3.2xlarge 实例的 vcore 数量是 m2.2xlarge 实例的两倍，而成本却不到后者多出 30%

测试方案考虑到这一切，我们针对下列事项对 m3.2xlarge 和 m2.2xlarge 实例上 Redis 的性能进行了比较：

• fork 时间
• 纯 n- 内存配置的吞吐量和延迟
• 在正常条件下（在 AOF 重写已禁用时）启用 AOF 的吞吐量和延迟
• 复制时间

测试复制时间很重要，因为 m3.2xlarge 不带临时存储或者更准确地说，仅配有 15GB 的本地磁盘大小。这意味着即便不需要数据持久性，也必须将其连接到 EBS 卷，因为 Redis 复制流程涉及将整个数据集写入持久存储两次（在主磁盘，然后在从磁盘）。由于 EBS 在顺序写入方面的速度较慢（更多详细信息，请参阅此处），我们希望看到 Redis 复制是否以及如何受此配置的影响。事实上，这是我们的研究结果：fork 时间

正如预期的那样，使用 m3.2xlarge 实例的 fork 时间显著低于 m2.2xlarge 实例上的 fork 时间，因为它采用了 Xen 全虚拟化模式 (HVM)。AWS 集群计算实例上也观察到了类似的低 fork 时间结果（更多信息，请参阅此处），但实例成本要高得多。 吞吐量和延迟我们比较了两个实例上单片式 Redis 的吞吐量和延迟，以下是我们得到的结果

我们的见解

• 在每次测试中，m2.2xlarge 的吞吐量都高出大约 15%，而延迟却低了大约 12%。这是我们预料之中的，因为完全虚拟化的访客（HVM）通常比准虚拟化的访客慢，因为需要仿真。
• 当我们在使用准虚拟化 AMI 的 m3.2xlarge 实例上运行 Redis 时，我们看到了与单片式 Redis 性能相同，但在 fork 时间上没有改进。
• 在具有多个 Redis 进程的环境中（即多个专用 Redis 数据库或多片式 Redis ），当活动的进程数量超过 m2.2xlarge 实例的 4 个 vcore 时，我们希望 m3.2xlarge 能够运行得更好

复制时间

为了测量复制时间，我们在将从库连接到主库后开始进行测量，并在从库同步后停止测量。虽然我们对 m2.2xlarge 实例进行了配置，使其使用以 80 MB/s（峰值）运行的本地磁盘接口，并且对 m3.2xlarge 进行配置，使其使用以 30 MB/s（峰值）运行的 EBS 接口，但 m2.2xlarge 实例的总复制时间仅增加了 13%。我们认为这是因为填充过程在该大小的 RDB 文件方面消耗了大量时间。我们假设填充时间与整个复制过程的比率与 RDB 文件的大小线性增长。因此，文件越大，磁盘访问吞吐量对整个复制过程的影响就越小。小型 RDB 文件的复制固然很快，因此可以安全地假设吞吐量较高的存储接口不会显著影响整个复制过程。  结论 带有 HVM AMI 的 AWS 新 M3 实例完全消除了 Xen 分叉时间问题，该问题显著影响了 Redis 在执行实时快照或重写只追加文件 (AOF) 后台保存进程期间的性能。另一方面，在纯内存测试和 AOF 测试中，m3.2xlarge 实例上单线程 Redis 服务器的性能比 m2.2xlarge 实例的性能慢约 15%。m2.3xlarge 实例的复制时间也较慢，但没有我们预期的那么明显。我们的建议是仅在无需复制的情况下运行 Redis 或需要在同一实例上运行四个以上的 Redis 进程时才在 m3.2xlarge 上使用 Redis。对于所有其他情况，我们仍建议使用 m2.2xlarge 实例。  测试设置 对于希望了解有关我们的测试的更多详细信息的人们，以下是我们使用的资源

• 在以下配置上使用 Redis Cloud
  • 2x m3.2xlarge 实例
  • 2x m2.2xlarge 实例
• 在两种配置中，我们都使用了标准 EBS 卷：100GB（非 RAID）

这是我们用于生成负载的设置：运行我们的 memtier_benchmark 负载生成工具（我们开发的一个高级负载生成工具，我们很快将在我们的github 帐户中分享该工具）的 m2.2xlarge 实例。 为了测试分叉时间，我们执行了以下步骤

• 我们使用不同数据类型的各种对象填充内存
• 我们启用了 AOF 并一直等到第一次重写操作完成
• 我们使用 memtier_benchmark 生成了随机密钥上的高负载，以便尽可能多地访问内存页面
• 我们执行了 GBREWRITEAOF
• 我们读取了 Redis INFO 的latest_fork_usec 值

对于测试吞吐量和延迟，我们运行了 2 次测试

• 禁用数据持久性
• 使用“每秒 fsync”的 AOF

我们使用以下参数在每个配置中运行了三次每个测试，并计算出了平均结果

• 100 个连接
• 随机 100B-1000B 对象大小
• 1/1 GET/SET 比例

为测试复制，我们

• 已禁用数据持久性
• 使用不同数据类型的各种对象填充内存
• 断开从属服务器
• 在重新将从属服务器连接到主服务器时开始测量
• 在从属服务器同步时停止测量
• 同时，我们继续在主服务器上生成应用程序负载