《MySQL排错指南》——4.1 物理硬件限制-阿里云开发者社区

开发者社区> 数据库> 正文

《MySQL排错指南》——4.1 物理硬件限制

简介:

本节书摘来自异步社区出版社《MySQL排错指南》一书中的第4章,第4.1节,作者:【美】Sveta Smirnova(斯维特 斯米尔诺娃),更多章节内容可以访问云栖社区“异步社区”公众号查看。

4.1 物理硬件限制

对性能有不切实际的期望是通常会犯的错。我们要求MySQL服务器在忽略硬件组件延迟的情况下进行优化。因此,理解什么导致了延迟很重要。

下面列出了影响MySQL服务器的硬件资源:

内存
CPU
内核数量
磁盘I/O
网络带宽
我们依次讨论每个细节。

4.1.1 内存

内存对于MySQL是非常宝贵的资源。服务器在没有磁盘交换的情况下运行很快。理想情况是数据驻留在内存中。因此,在物理内存的限制内合理配置缓冲区是非常重要的。关于这一点,1.6.4小节和3.9.3小节提供了更多详细的介绍和指导。

提示 提示

在Linux/UNIX上可以通过vmstat,或者Windows上的任务管理器来查看mysqld是否有大量磁盘交换。

这里列出Linux上一个磁盘交换的例子。重要的部分加粗显示。对于没有磁盘交换的服务器,这些值应该为0:
image

相关章节讨论了影响内存使用的配置变量。首先计算出MySQL服务器需要用到的最大内存量,基本原则是要保证它小于你的物理内存。当缓冲区大于实际内存时会增加MySQL服务器因为“内存不足”错误而崩溃的风险。

前面的观点可以换一种陈述方式:如果你需要更大的缓冲区,则需要购买更多内存。扩展应用程序时这始终是一个很好的做法。
使用的内存模块支持扩展错误校正(EEC),这样即使内存有一些损坏,MySQL服务器也不会因此崩溃。
关于内存使用的更多内容,可以参考MySQL参考手册中的“MySQL如何使用内存”章节。我就不在此处重复,因为它不涉及任何新排错技巧。

很重要的一点是,当查询的行包含BLOB字段时,内部缓冲区会增长到能存储该值的点,并且存储引擎在查询结束后不会释放内存。需要执行FLUSH TABLE来释放内存。

另一个要点涉及32位和64位架构的不同。虽然32位使用较小的指针大小可以节约内存,但由于操作系统的寻址受限,它在缓冲区大小设置上存在固有的约束。理论上,每个进程在32位系统上的最大可用内存为4GB,实际上在很多系统上这个数值很小。所以如果你想使用的缓冲区在32位系统上超过了这个值,考虑转换到64位架构下。

4.1.2 处理器与内核

MySQL的性能不会随着CPU的速度线性增长。这并不意味着你不能使用一块快的CPU,但不要期望提高CPU速度能像增加内存那样性能会有大幅提升。

然而,当设置一些影响内部线程并发的选项时,内核的数量很重要。如果你没有足够的内核数增加这些值是没有任何意义的。通过使用一款名叫sysbench[1]的基准工具能够轻松说明问题。表4-1显示了在四核机器上的一个测试结果。我使用具有16个线程的OLTP sysbench测试。

表4-1 不同innodb_thread_concurrency值下执行事件消耗的时间(s)

image

如你所见,在启动8个线程之前测试越运行越快,但随着数值的增加停止了增长。

4.1.3 磁盘I/O

快速磁盘对MySQL性能很重要。磁盘越快,I/O性能越好。

关于磁盘,你需要关注磁盘读延迟(每次读访问需要多长时间)和fsync延迟(每个fsync耗时多少)。

近来固态硬盘(SSD)的性能很好,但不要指望在上面出现奇迹,因为大多数存储引擎是针对硬盘读写优化的。

同样网络存储也是。可以将数据和日志文件放在网络文件系统或者存储上,但这些装置可能会慢于本地磁盘。你需要检查存储是否快速并且可靠,否则,如果由于网络故障引起数据丢失请不要感到意外。

在Linux/UNIX上使用iostat来判断磁盘I/O是否过载。向设备发起的请求平均队列长度正常情况下不会很高。出于同样的目的,你可以在Windows平台上使用perfmon。下面给出iostat的一个输出例子:

image

以上输出取自mysqld空闲并随后启动一个活跃的I/O作业时。你可以看到avgqu-sz是如何增长的。虽然还不至于带来问题,但我决定在这里通过这个例子来说明当mysqld正在处理它的作业时磁盘I/O活动是如何发生变化的。

除了速度之外,要牢记的是,存储也可能会丢失数据,可能出现只写入一部分页的情况。如果使用InnoDB,为了数据安全通过设置innodb_double_write使用双写缓冲区。同样,为磁盘准备备用电池是很重要的,它可能防止因为电源故障导致的数据丢失。

4.1.4 网络带宽

客户端几乎总是通过网络连接MySQL到服务器的,所以MySQL服务器运行在一个快速的网络环境下是很重要的。

除了网络带宽之外,往返时间(RTT)和往返次数也很重要。RTT指的是客户端发送网络包到服务端返回应答所消耗的时间。主机间隔的距离越长,RTT越高。

也正是因为存在网络带宽和RTT这些原因,如果可以,推荐将客户端和服务器放在同一个本地网络中。

复制也推荐在本地网络中进行。连接到从服务器时可以使用因特网来替代本地内联网,但预期会出现延迟,甚至中继日志数据损坏带来的报错。上面的错误应该在bug #26489 bug修复之后会自动修复,前提是你在5.5版本中配置了relay-log-recovery选项,或者从5.6版本开始使用二进制日志校验和。但由于网络故障主从服务器之间仍然会在重发包上消耗时间。

4.1.5 延迟效应的例子

为了结束本章内容,我用一个小例子来说明硬件延迟是如何影响一条普通的UPDATE查询的。我们使用InnoDB表并将自动提交打开,同时打开二进制日志文件。

image

这个简单的查询会在下面的情况下遭遇延迟:

  客户端发送命令到服务端历经半个RTT。

  执行UPDATE的WHERE子句,mysqld读磁盘。

  由于自动提交开启mysqld会对此事务做一个fsync调用。

  为写入二进制日志文件Mysqld做一次fsync调用。

  为提交改变mysqld做一次fsync调用。

  客户端收到来自服务器的结果,这是RTT的另一半。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章