EC2/EBS 上的 MySQL。太慢了？

Question

我在 AWS 上有一个 MySQL m2.2xlarge 实例。 MySQL 数据目录位于根 EBS/。它是单个 EBS 而不是 RAID。我们有三个主要表。其中一个Table C，内容最大，只使用了最近几天的数据。这些表中的插入率约为每天 80.000 行。这 3 个表有大约 4200 万行。 innodb_buffer_pool_size 有大约 30GB 的实例 RAM。

Table A 是最重要的，它的数据长度约为 33GB，索引约为 11GB表 B 的数据长度约为 8GB，索引约为 5GB

在我们的网站中，两个主要查询(延迟方面)是这样的:

SELECT * FROM TableA WHERE id in (.....)

SELECT * FROM TableB JOIN .... WHERE id in (.....)

在大多数页面中，(...) 将是大约 50 个最近的 ID，这些查询每次花费 < 50 毫秒。但在其他一些页面中，我们命中了较旧的 ID，这些查询的延迟飙升至 500 毫秒、800 毫秒，最高可达 1.5 秒。

我做了一个测试，在 Mysql 重启后，我做了一个 SELECT id FROM TableB 来强制索引到缓存/内存中。 Table B 查询仍然很慢。然后我执行了 SELECT * FROM TableB。现在整个表都在缓存/内存中，查询变得非常快(<50 毫秒)。

我的问题:> 500 毫秒，> 1000 毫秒对于仅通过主键检索行的查询来说是合理的延迟吗？即使在42M的表中？即使所有行都在磁盘中？这对我来说似乎太多了。

将 MySQL 数据移动到临时存储 (/mnt) 会改善这种情况吗？使用预配置 IOPS 有帮助吗？

Answer 1

免责声明:我根本不是 (My)SQL 性能方面的专家，只是评论您用例的 AWS 方面。

除此之外，还有几个问题需要解决，首先也是最重要的:

Would moving MySQL data to ephemeral storage (/mnt) improve this?

我已经为相同的问题提供了答案 Will moving data from EBS to ephemeral storage improve MySQL query performance? ，请查看一些重要的细节 - 长话短说:如果您有任何持久性需求(除非您确切知道自己在做什么)，并且通过声明中的临时存储获得性能提升，您绝对不想这样做从今天的角度来看，即使不是完全错误，过去也充其量是可疑的。

Would using Provisioned IOPS help with?

当然，Provisioned IOPS Volumes专门设计用于满足 I/O 密集型工作负载的需求，尤其是数据库工作负载，这些工作负载对存储性能和随机访问 I/O 吞吐量的一致性很敏感，请参阅帖子 Fast Forward - Provisioned IOPS for EBS Volumes进行一般介绍。

• 请注意，这些理想情况下(但不一定)与 EBS-Optimized Instances 齐头并进。 ，它使用优化的配置堆栈并为 EBS I/O 提供额外的专用容量。此优化通过最大限度地减少 EBS I/O 与来自您的 Amazon EC2 实例的其他流量之间的争用，为您的 EBS 卷提供最佳性能。

• 具体来说，您需要通读专用部分 Increasing EBS Performance ，它解决了如何查看您需要的 I/O 性能，以及如何通过 RAID 和/或预置 IOPS 来提高 EBS 性能以满足这些要求，具体取决于您的使用情况案例。

My question: > 500 ms, > 1000ms is a reasonable latency for a query that just retrieves rows by PRIMARY KEY? Even in a 42M table? Even when all rows are in disk? It seems too much for me.

如前所述，我无法判断这些值，但是，鉴于您的规范，您似乎存在内存争用，目前 m2.2xlarge 实例“仅”具有 34.2 GiB 的内存，而您正在为 innodb_buffer_pool_size 已经-考虑到操作系统和/或 MySQL 的其他内存要求，这对我来说似乎有点高，因此可能已经涉及交换，这将完美地解释您的缓存/内存预热行为体验。

• 作为针对数据库工作负载的一般建议，这似乎是目前为止最划算的方法，只需确保您的数据集完全适合 RAM，这对于过多的实例类型(如果可行的话)来说比以往任何时候都容易首先)。

最后，我建议阅读最近关于 Improving PostgreSQL performance on AWS EC2 的帖子- 那里的建议也主要针对 AWS 方面的问题，并且相应地也适用于 MySQL； 持久数据库部分几乎总结了我上面的建议:

For a durable database where you care about your data, what you want instead of a high I/O instance is an EBS Optimized instance, which has guaranteed network bandwidth to the EBS storage servers. Use EBS volumes with provisioned IOPs and, for best results, stripe a group of EBS volumes into a RAID10 array. See increasing EBS performance.