MySQL在EC2/EBS上.太慢了？

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,这些查询每个小于50毫秒.但在其他一些页面中,我们遇到了较旧的ID,这些查询的延迟时间猛增至500毫秒,800毫秒,最长1.5秒.

我做了一个测试,在Mysql重启之后,我做了一个SELECT id FROM TableB强制索引进入缓存/内存.该Table B查询将仍然是缓慢的.然后我做了一个SELECT * FROM TableB.现在,在缓存/内存中的整个表中,查询变得非常快(<50ms).

我的问题:> 500毫秒,> 1000毫秒是一个合理的延迟,只是通过PRIMARY KEY检索行的查询？即使在42M的桌子上？即使所有行都在磁盘中？对我来说似乎太过分了.

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

Answer 1

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

除此之外,还有几个问题需要解决,首先是:

将MySQL数据移动到短暂存储(/ mnt)会改善这个吗？

我已经为相同的问题提供了答案将数据从EBS移动到临时存储会提高MySQL查询性能吗？请查看一些重要细节 - TL; DR:如果您有任何耐久性需求(除非您确切知道自己在做什么),否则您绝对不希望这样做,并且通过临时存储声明的性能提升从今天的角度来看,过去也是充满疑问的,如果不是完全错误的话.

使用预配置IOPS会有帮助吗？

绝对地,预配置IOPS卷专门设计用于满足对存储性能和随机访问I/O吞吐量一致性敏感的I/O密集型工作负载(尤其是数据库工作负载)的需求,请参阅EBS后快速转发 - 预配置IOPS一般介绍的卷.

• 请注意,这些理想情况(但不一定)与EBS优化实例密切相关,EBS优化实例使用优化配置堆栈并为EBS I/O提供额外的专用容量.此优化通过最大限度地减少EBS I/O与Amazon EC2实例的其他流量之间的争用,为您的EBS卷提供最佳性能.

• 具体来说,您需要阅读专用部分" 提高EBS性能",其中介绍了如何查看所需的I/O性能以及提高EBS性能的选项,以满足 RAID和/或预配置IOPS的要求,具体取决于您的使用情况案件.

我的问题:> 500毫秒,> 1000毫秒是一个合理的延迟,只是通过PRIMARY KEY检索行的查询？即使在42M的桌子上？即使所有行都在磁盘中？对我来说似乎太过分了.

如上所述,我无法判断这些值,但是,鉴于您的规范,您似乎存在内存争用,m2.2xlarge实例仅具有"仅34.2 GiB内存"并且您innodb_buffer_pool_size已为此分配~30GB - 这似乎考虑到操作系统和/或MySQL的其他内存要求,对我来说有点高,所以可能已经涉及交换,这将完美地解释您遇到的缓存/内存升温行为.

• 作为数据库工作负载的一般建议,到目前为止,它似乎是迄今为止最大的优势,只需确保您的数据集完全适合RAM,这比以往任何时候都容易使用过多的实例类型(如果在第一个可行的情况下完全可行)地点).

最后,我建议阅读最近关于在AWS EC2上改进PostgreSQL性能的帖子- 其中的建议主要针对AWS方面,并相应地适用于MySQL; 部分持久数据库几乎总结了我上面的建议:

对于您关心数据的持久数据库,您想要的而不是高I/O实例是EBS优化实例,它保证了EBS存储服务器的网络带宽.使用具有预配置IOP的 EBS卷,并且为了获得最佳结果,将一组EBS卷条带化为RAID10阵列.请参阅提高EBS性能.