Julio Suarez
合著者: Manoj Iyer, Julio Suarez
2021 年 6 月 9 日
在这篇博文中，我们探讨了 MongoDB 在基于 AWS Graviton2 的 Amazon EC2 R6g 实例上的开箱即用性能。我们展示了 R6g 实例如何实现比基于英特尔至强的 R5 实例高 117% 的吞吐量。R6g 实例的成本也比 R5 实例低 20%，这使 AWS Graviton2 在运行 MongoDB 方面比 Xeon 具有显着的每美元性能优势。
基于 Arm 的 AWS Graviton2
AWS Graviton2 是由 Annapurna Labs 构建的基于Arm Neoverse N1 内核的定制处理器 。有多种基于 Graviton2 的 EC2 实例类型。其中包括通用 M6g、M6gd 和 T4g、计算优化的 C6g、C6gd 和 C6gn，以及内存优化的 R6g、R6gd 和 X2gd 实例。
MongoDB
MongoDB 是于 2009 年首次发布的 NoSQL 数据库。从那时起，MongoDB 已在各个组织和行业中得到广泛采用。
针对 MongoDB 的 Arm 特定更新
在过去的几年里，MongoDB 代码库不断更新以针对 Arm 进行优化。例如，更好地支持 AArch64（又名 arm64），改进的 指令缓存 处理，以及 用ISB 指令（指令同步屏障）替换 Arm yield指令 。这促使我们研究 MongoDB 在 Graviton2 上的性能。
测试设置和方法
设置
执行的每个测试由一个负载生成器实例和一个被测实例组成。负载生成器运行 YCSB 来生成负载。未使用复制，因为我们正在测试 MongoDB 的单个实例。在测试时，某些特定于 Arm 的更改不在 MongoDB 的最新版本中。为此，我们测试了使用 GCC 10.3 编译的标签 v5.0.0-alpha0-179-g3c818a3。下表显示了经过测试的实例。
下表描述了我们使用的负载生成器
客户端线程的数量是通过实验确定的。从 1 开始，我们增加线程数，直到第 99 个百分位延迟开始增加，吞吐量开始下降。我们决定使用 96 个线程，因为它似乎是性能开始下降的拐点。
方法
我们使用 YCSB工作负载 F测试了 INSERT、RMW 和 UPDATE 操作 . 对于测试的每个操作，我们绘制了两个图。第一张图显示了目标吞吐量与实际吞吐量的对比。目标吞吐量是负载生成器发出的每秒操作数 (ops/s) 的事务率。实际吞吐量衡量实例能够根据目标吞吐量负载维持的操作数。这张图让我们可以看到每个实例的吞吐量饱和的位置，与理想的扩展进行比较，并在吞吐量饱和之前和之后的实例之间进行比较。第二个图绘制了目标吞吐量与延迟（99 个百分位数）的关系。出于易读性的目的，我们用目标吞吐量而不是实际吞吐量绘制延迟图，因为一旦我们越过吞吐量饱和点，图就会变得极度倾斜。只要我们注意吞吐量饱和发生的位置，我们仍然可以从目标吞吐量与延迟图中得出含义。我们将在下一节中探讨这些测试结果。
主要发现
MongoDB 插入结果
图 1 的左侧表示低负载情况。在这里，我们看到 R6g 和 R5 的实际吞吐量大致相等。我们还可以看到实际吞吐量密切跟踪目标吞吐量（即理想缩放）。然而，随着我们增加负载（向右移动），我们会遇到每种实例类型的饱和点。R6g 的饱和速度约为 64.8k ops/s，R5 的饱和速度约为 29.8k ops/s。因此，在高负载下，R6g 的吞吐量比 R5 高约 117%。接下来，让我们看看与之前显示的吞吐量数据相关的延迟图。
平均而言，R6g 的延迟比 R5 高约 16%，但当目标负载很高（110,000+ ops/s）时，它的延迟也降低了 3% 到 9%。这表明在延迟方面可能存在显着的运行差异。这将需要重复性测试，因为尚不清楚这些低于 1 毫秒的 p99 延迟差异是否显着。无论如何，在查看延迟图时，我们还必须记住，R6g 的吞吐量比 R5 高 117%，成本低 20%。鉴于这些显着优势，平均延迟高 16% 看起来是一个可以接受的折衷。
MongoDB RMW 和 UPDATE 结果
我们在图 3 中注意到的第一件事是，R6g 和 R5 都不能很好地跟踪目标吞吐量（理想的缩放比例）。即使在 200 ops/s 的最低目标吞吐量下，R6g 和 R5 都比目标吞吐量低约 17%。R6g 和 R5 的结果相似，最高可达 50,000 ops/s，其中 R6g 的吞吐量比 R5 高 2%。请注意，我们在图 3 中同时包含了 RMW 和 UPDATE 实际吞吐量，因为测试结果是相同的。
在 MongoDB RMW 上，R6g 和 R5 p99 延迟密切跟踪彼此。延迟比 R5 低约 1.3%。与 INSERT 一样，对 p99 延迟进行可重复性分析可能是一个好主意。总体而言，R6g 在 RMW 方面比 R5 具有边际吞吐量优势。
平均而言，R6g 和 R5 之间的 UPDATE p99 延迟非常相似，因此我们应该考虑两个实例之间的延迟相等。与其他操作类型一样，应对 p99 延迟进行可重复性分析。
结论
基于上面显示的开箱即用性能，我们鼓励读者使用任何基于 AWS Graviton2 的 EC2 实例尝试他们的 MongoDB 部署。我们的测试结果表明，对于 INSERT，R6g 的性能明显优于 R5（高达 117%）。在 RMW 和 UPDATE 方面，R6g 略胜于 R5。鉴于 R6g 的成本降低了 20%，这使得 R6g 成为运行 MongoDB 的经济高效的选择。
有关开始使用 AWS Graviton2 的更多详细信息，请访问此github 页面。有关在 Arm Neoverse 平台上运行您的软件工作负载的任何疑问，请随时通过sw-ecosystem@arm.com与我们联系。
