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 Table B的数据长度为~8GB，索引为~5GB

在我们的网站上，两个主要的查询（延迟方面）是这样的：

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

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

在大多数页面中，（...）将是约50个近期的ID，这些查询采用＆lt;每个50毫秒。但在其他一些页面中，我们遇到了较旧的ID，这些查询的延迟时间猛增至500毫秒，800毫秒，最长1.5秒。

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

我的问题：＆gt; 500毫秒，＆gt;对于只通过PRIMARY KEY检索行的查询，1000ms是合理的延迟吗？即使在42M的桌子上？即使所有行都在磁盘中？对我来说似乎太过分了。

将MySQL数据移动到短暂存储（/ mnt）会改善这个吗？使用预配置IOPS会有帮助吗？

Answer 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齐头并进，Increasing EBS Performance使用优化配置堆栈，并为EBS I / O提供额外的专用容量。此优化通过最大限度地减少EBS I / O与Amazon EC2实例的其他流量之间的争用，为您的EBS卷提供最佳性能。
具体而言，您需要阅读专门的Improving PostgreSQL performance on AWS EC2部分，其中介绍了如何查看所需的I / O性能以及提高EBS性能以满足这些要求的选项使用RAID和/或预配置IOPS ，具体取决于您的使用情况。

我的问题：＆gt; 500毫秒，＆gt;对于只通过PRIMARY KEY检索行的查询，1000ms是合理的延迟吗？即使在42M的桌子上？即使所有行都在磁盘中？对我来说似乎太过分了。

如上所述，我无法判断这些值，但是，根据您的规范，您似乎存在内存争用，m2.2xlarge实例仅具有'34.2 GiB内存，而您为{分配~30GB已经{1}} - 考虑到操作系统和/或MySQL的其他内存要求，这对我来说似乎有点高，因此可能已经涉及交换，这将完美地解释您遇到的缓存/内存升温行为。< / p>

作为数据库工作负载的一般建议，到目前为止，确保您的数据集完全适合RAM，这似乎是迄今为止最大的砰砰声，这对于过多的实例类型来说比以往更容易（如果可行的话）首先）。

最后，我建议阅读最近关于EBS Optimized instance的帖子 - 那里的建议主要涉及AWS方面，并且也适用于MySQL;部分耐用数据库几乎总结了我上面的建议：

对于您关心数据的持久数据库，您需要的是provisioned IOPs而不是高I / O实例，它保证了EBS存储服务器的网络带宽。使用带有increasing EBS performance的EBS卷，为了获得最佳结果，将一组EBS卷条带化为RAID10阵列。请参阅{{3}}。

Answer 2

如果IN语句包含SQL-subquery而不是EC2实例可能会非常慢，因为默认情况下它使用MySQL 5.5（详情请参见MySQL is extremely slow on EC2）

MySQL在EC2 / EBS上。太慢了？

2 个答案: