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性能的指标。

【测试1、比较HP SSD Smart Path开启先后SSD的写入性能】

一、HP SSD Smart Path开启，SSD控制器Caching关闭，Cache Ratio: 100% Read / 0% Write

测试结果以下，主要关注D2C（IO请求在SSD上消耗的时间）的AVG值，约为0.217ms

二、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开启

 

【测试2、比较noop和deadline两种I/O调度算法的性能】

目前磁盘的调度算法有以下四种，咱们系统中的配置值为deadline，不少资料上建议SSD配置为noop

一、Anticipatory，适用于我的PC，单磁盘系统；

二、CFQ(Complete Fair Queuing)，默认的IO调度算法，彻底公平的排队调度算法

三、Deadline，按照截止期限来循环在各个IO队列中进行调度

四、noop，简单的FIFO队列进行调度

下面都在HP SSD Smart Path关闭的状况下测试，

一、deadline, 主要关注G2I和I2D

二、修改成noop

 

【结论】

noop的IO Scheduler在等待和消耗的时间比deadline稍好，但差别不是很大。若是须要评估，还须要进一步详细的在各个场景下的测试。

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

 

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

AVG D2C为0.0906ms，0.0934ms，差别不大，说明这台服务器的SSD从响应时间上正常