EC2/EBS 上的 MySQL。太慢了？答案

【问题标题】：MySQL on EC2/EBS. Too slow?EC2/EBS 上的 MySQL。太慢了？
【发布时间】：2013-01-28 04:09:24
【问题描述】：

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

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

在我们的网站中，两个主要查询（延迟方面）如下所示：

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

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

在大多数页面中，(...) 将是大约 50 个最近的 id，这些查询每个耗时

我做了一个测试，在 Mysql 重新启动后，我做了一个SELECT id FROM TableB 来强制索引到缓存/内存。 Table B 查询仍然很慢。然后我做了一个SELECT * FROM TableB。现在有了缓存/内存中的整个表，查询变得非常快（

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

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

【问题讨论】：

您使用的是单个 EBS 卷还是 RAID 集？如果没有可靠的复制，使用 /mnt 可能会有些风险。您可以测试预置的 IOPS，而无需自己承担太多成本。
单个 EBS。我想如果不将整个数据集转储到新的 EBS 卷，我就无法转移到预置的 IOPS。所以我想先了解一些知识是否值得搬家。
我认为您可以对您的卷进行 snapshop 并从 snapshop 中创建一个带有预置 IO 的新卷。然后将其附加到一个新实例以对其进行测试。 ec2 的好处是可以灵活地配置新实例来测试性能变化，而无需提交。

标签： mysql amazon-web-services amazon-ec2

【解决方案1】：

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

除此之外，首先要解决几个问题：

将 MySQL 数据移动到临时存储 (/mnt) 会改善这一点吗？

我已经为Will moving data from EBS to ephemeral storage improve MySQL query performance? 提供了相同问题的答案，请查看它以了解一些重要细节 - TL;DR：如果您有任何耐用性需求，您绝对不想这样做（除非您确切地知道您在做什么），并且过去声称通过临时存储获得的性能提升也充其量是可疑的，如果从今天的角度来看不是完全错误的话。

使用预置 IOPS 有帮助吗？

当然，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 性能以及提高 EBS 性能以满足这些要求的选项 em> 使用 RAID 和/或 预置 IOPS，具体取决于您的用例。

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

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

作为对数据库工作负载的一般建议，目前看来最划算的是，只需确保您的数据集完全适合 RAM，这比以往任何时候都更容易使用过多的实例类型（如果可行的话）首先）。

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

对于您关心数据的持久数据库，您需要的是EBS Optimized instance，而不是高 I/O 实例，它保证了 EBS 存储服务器的网络带宽。将 EBS 卷与 provisioned IOPs 一起使用，并为获得最佳效果，将一组 EBS 卷条带化到 RAID10 阵列中。见increasing EBS performance。

【讨论】：

【解决方案2】：

如果您在 IN 语句中包含 SQL 子查询，则 EC2 实例可能会非常慢，因为默认情况下它使用 MySQL 5.5（有关详细信息，请查看 MySQL is extremely slow on EC2）

【讨论】：