MySQL服务器的SSD性能问题分析和测试详解

【问题】

我们有台hp的服务器，ssd在写iops约5000时，%util达到80%以上，那么这块ssd的性能究竟有没有问题，为解决这个问题做了下面测试。

【工具】

blktrace是linux下用来排查io性能的工具。它可以记录io经历的各个步骤，并计算出io请求在各个阶段的消耗，下面是关键的一些步骤：

q2g – 生成io请求所消耗的时间，包括remap和split的时间；

g2i – io请求进入io scheduler所消耗的时间，包括merge的时间；

i2d – io请求在io scheduler中等待的时间；

d2c – io请求在driver和硬件上所消耗的时间；

q2c – 整个io请求所消耗的时间(g2i + i2d + d2c = q2c)，相当于iostat的await。

其中d2c可以作为硬件性能的指标，i2d可以作为io scheduler性能的指标。

【测试一、比较hp ssd smart path开启前后ssd的写入性能】

1、hp ssd smart path开启，ssd控制器caching关闭，cache ratio: 100% read / 0% write

测试结果如下，主要关注d2c（io请求在ssd上消耗的时间）的avg值，约为0.217ms

2、hp ssd smart path关闭，ssd控制器caching开启，cache ratio: 10% read / 90% write

测试结果如下，主要关注d2c（io请求在ssd上消耗的时间）的avg值，约为0.0906ms

【结论】

前者在硬件上的消耗时间是后者的约2.4倍，对于写入为主的系统，建议hp ssd smart path关闭，ssd控制器caching开启

【测试二、比较noop和deadline两种i/o调度算法的性能】

目前磁盘的调度算法有如下四种，我们系统中的配置值为deadline，很多资料上建议ssd配置为noop

1、anticipatory，适用于个人pc，单磁盘系统；

2、cfq(complete fair queuing)，默认的io调度算法，完全公平的排队调度算法

3、deadline，按照截止期限来循环在各个io队列中进行调度

4、noop，简单的fifo队列进行调度

下面都在hp ssd smart path关闭的情况下测试，

1、deadline, 主要关注g2i和i2d

2、修改为noop

【结论】

noop的io scheduler在等待和消耗的时间比deadline稍好，但差异不是很大。如果需要评估，还需要进一步详细的在各个场景下的测试。

下图是网上资料对不同调度算法的测试比较：

【测试三、比较这台服务器ssd与相同配置ssd的消耗时间】

avg d2c为0.0906ms，0.0934ms，差异不大，说明这台服务器的ssd从响应时间上正常

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对的支持。