默认设置可以帮助你开始迅速——但他们也可以花费你的性能和更高的云比尔在本月底。想节省你的AWS RDS账单吗?我将向您展示一些MySQL设置优化获得更好的性能,节约成本,AWS RDS。
最近我参与MySQL绩效审计客户来帮助解决性能问题导致停机期间高流量的AWS RDS MySQL实例。在高负载时,他们会看到错误日志中的消息InnoDB的设置:
|
1
|
(
请注意
]
InnoDB
:
page_cleaner
:
1000毫秒
目的
循环
花了
4460 ms。
的
设置
可能
不
是
最优
。
(
刷新
=
140年
,
在
的
时间
。
)
|
这个消息通常是一个副作用的存储子系统不能跟上写的数量(例如,IOPs)所需的MySQL。这是“嘿,MySQL,试着写更少。我跟不上”,这是一种常见的情况当innodb_io_capacity_max设置过高。
经过一段时间的接收这些消息,最终,他们冲击性能问题,服务器无响应了几分钟。之后,一切回到正常。
让我们来看看这个问题,尝试收集一些上下文信息。
调查AWS RDS性能问题
我们有一个db.m5.8xlarge实例类型(32个vcpu - 128 gb的RAM)的gp2存储5结核病,它应该提供多达10000 IOPS(这是最大容量允许的gp2),运行MySQL 5.7。这是一个非常不错的设置,我不认为许多客户需要写这么多持续IOPS。
的innodb_io_capacity_max参数被设置为2000,所以硬件应该能够提供许多IOPS没有重大问题。然而,gp2面临棘手的计算学分和使用方式可能驱动错误结论的实际能力存储。回顾CloudWatch图形,我们只有大约8-9k IOPS(读和写)峰值期间使用。
IO利用率相当高的时候,应该有一些空间来得到更多的IOPS,但是我们仍然看到错误。是什么引起了我的注意MySQL几分钟后所表现出的自我修复条件。
通常,共同讨论解决方案,实际上是在我们开始叫,“好吧,总有机会供应IOPS,但这是非常昂贵的。“是的,这是真的,io2卷是昂贵的,老实说,我认为他们应该只在使用真的高IO能力预期延迟是必需的,这似乎并不如此。
否则,大部分的环境能够适应gp2 / gp3卷;对于这个问题,你需要提供一个足够大的体积和足够的IOPS。
找到与pt-mysql-summary“确凿证据”
不久前,我的同事伊夫•特鲁多我工作在一系列文章讨论如何配置实例写密集型工作负载。快速浏览一下pt-mysql-summary输出显示了一些有趣的,当接近问题的繁忙时期负荷:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20.
21
22
23
24
|
# InnoDB # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
版本
|
5.7.38
缓冲
池
大小
|
93.0克
缓冲
池
填满
|
One hundred.
%
缓冲
池
脏
|
1
%
文件
每
表
|
在
页面
大小
|
16 k
日志
文件
大小
|
2
*
128.0米
=
256.0米
日志
缓冲
大小
|
8米
冲洗
方法
|
O
_直接
冲洗
日志
在
提交
|
1
XA
支持
|
在
校验和
|
在
Doublewrite
|
在
R
/
W
我
/
O
线程
|
4
4
我
/
O
能力
|
200年
线程
并发性
|
0
并发性
票
|
5000年
提交
并发性
|
0
时候
隔离
水平
|
可重复的
- - - - - -
读
自适应
冲洗
|
在
自适应
检查点
|
检查点
年龄
|
78米
InnoDB
队列
|
0
查询
内部
InnoDB
,
0
查询
在
队列
|
等等,什么?256岁的重做日志和检查点只有78 ?这是相当保守,考虑一个93 gb的缓冲池大小。我猜我们应该承担这么大的大的重做日志缓冲池。宾果!这里有确凿的证据。
此外,完整的ACID特性被启用,这是innodb_flush_log_at_trx_commit= 1,sync_binlog= 1,增加很多开销写每个操作,因为在提交阶段,一切都刷新到磁盘(或在这种情况下gp2)。
考虑高峰负荷运行很多编写查询,达到最大检查点年龄在此设置是一个很有可能的情况。
基本上,MySQL会执行刷新操作以一定速度取决于几个因素。这个速度通常是接近innodb_io_capacity在默认情况下(200);如果写的数量开始马克斯检查点方法时代,然后自适应冲洗算法将开始推高innodb_io_capacity_max默认(2000)尽量保持自由空间的重做日志的最大年龄限制检查站。
如果我们继续推动,最终我们可以达到最大检查点的年龄,这将驱动系统同步的状态,这意味着一种愤怒的冲洗操作将会发生innodb_io_capacity_max和所有的写操作将被暂停(冻结写),直到有免费的房间在重做日志保持写作。
这是这个服务器上到底发生了什么。我们计算每小时大概有多少写被执行,然后我们建议增加重做日志文件的大小为2 x2gb每个(4 gb)。实际上,3.7 g由于舍入,RDS,我们得到:
|
1
2
3
4
5
6
7
8
9
10
|
# InnoDB # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
版本
|
5.7.38
缓冲
池
大小
|
92.0克
缓冲
池
填满
|
One hundred.
%
缓冲
池
脏
|
2
%
文件
每
表
|
在
页面
大小
|
16 k
日志
文件
大小
|
2
*
1.9克
=
3.7克
日志
缓冲
大小
|
8米
冲洗
方法
|
O_DIRECT
|
然后我们也增加了innodb_io_capacity_max4000,所以我们让自适应冲洗算法提高写一些更多的空间。监测结果显示我们是正确的:
减少在过去几周是超过50%的IOPS,这是相当不错的了,我们没有改变硬件。实际上,可以减少3 tb的存储大小和避免搬到昂贵io2(供应IOPS)存储。
结论
RDS通常很有效的;大多数类型的实例的配置设置正常供应。不过,我发现,重做日志的RDS默认大小是这个小傻,人们使用完全托管解决方案希望不要担心一些常见的调优。
MySQL 8.0实现innodb_dedicated_server这个汽车大小innodb_log_file_size和innodb_log_files_in_group(现在取而代之的是innodb_redo_log_capacity)作为InnoDB的函数使用一个非常简单的缓冲池大小,但是有效,算法,我猜这应该不难AWS团队来实现它。我们做了一些研究,似乎RDS不是推动这个登录到8.0版本,这听起来很奇怪这样一个默认值innodb_redo_log_capacity
同时,检查如何RDS MySQL配置了默认参数是我们都应该审查,以避免典型的“投入更多的硬件解决方案”,通过扩展,花更多的钱。
雷竞技下载官网Percona顾问有几十年的经验解决复杂的数据库性能问题和设计挑战。他们会与你合作,理解你的目的和目标,并提供最好的,公正的解决方案为您的数据库环境。
个性化Percona数据库绩效雷竞技下载官网审计将有助于发现潜在的性能杀手在当前配置。
>不相信违约
这同样适用于一切;只接受默认设置如果你特别批准的目的。
嘿Jouni,我部分同意你的观点,我应该更多的强调,RDS完全管理理论上一个可以猜测或预期违约是好的(这就是为什么我们支付托管服务)。重点是关于一些违约是不正确的期望是什么。
我的2美分。