SQL Server 服务器磁盘测试之SQLIO篇（二）

         上次放出了一篇文章，针对磁盘卷簇大小默认4KB和自定义64KB进行了测试，测试内容为随机和顺序读写，大小为8KB和64KB，有人觉得这并没有照顾到SQL Server所有的IO使用情景。这篇测试文章，我们就来尽可能模拟一下SQL Server IO的行为，全方位对簇大小4KB、8KB和64KB做一次验证，注意：本次我们增加了簇为8KB的大小。

重点说明：本测试使用的是两块SSD组成的RAID1

首先，我们先来分析SQL Server的IO行为，参考网址：Choosing what SQLIO tests to Run and Automating the Tests

下面的几点是我根据文章整理，并非完全翻译：

1、SQL Server每个逻辑CPU上都会分配一个调度器，每个调度器上根据系统负载不同，会有多个Worker Thread，但是在同一个时刻，每个调度器上只能有一个Worker Thread处于运行状态，即：每个逻辑CPU在同一时刻只能支配一个Worker Thread干活。也就是说：SQLIO Param.txt 文件中定义的testfile.dat 8 0×0 5000 不能超过测试服务器逻辑CPU的数目，我测试的服务器为：2物理CPU*6核心*双线程=24逻辑CPU，即最大设置为：testfile.dat 24 0×0 5000

2、SQL Server间歇性的写入数据，写数据的行为由CheckPoint或者Lazy Writer(当内存有压力的时候）完成。当二者触发执行时，由单一的线程将内存中的脏页写入磁盘，因此当测试“写”的时候，在Param.txt 中配置超过1个线程都是毫无意义的，因为这种行为在即使多个数据库时也是串行的，(当然你可以配置线程数为2来压榨出IO写能力的极限)。并且，SQL Server在写入数据的时候，大部分情况下一次性写入32个page即256K的数据，因此你应该配置写入的Size为256K。但是也有例外，那就是Eager Writer，该行为在将数据库恢复模式设置为“大容量日志模式”时，最小化记录日志时将触发，该行为的写入Size为8KB(或者可能是64KB)。

3、SQL Server连续不断的进行数据读取操作，绝大多数的读操作是8KB为单位的，预读的块大小是64个page即512KB，直接读取整个区Extent即64KB也是较为常见的，因此对于读操作，测试8KB、64KB、512KB就可以了。

4、对于日志写，定一个测试Size是非常困难的，因为写入日志的大小取决于系统的负荷大小，但是一般不会超过60KB，但是对于测试，“我”建议使用8KB作为测试单位，这个大小覆盖了Eager Writer和Log Writer。在微软亚太博客的这篇文章中：SQL server每个日志写(log write)究竟有多大？，我们也可以了解到，SQL Server的日志写确实很不固定，一个简单的commit是512byte，而负荷较高时，接近60KB，在这里，我决定擅自再使用一个接近512byte的1KB作为测试大小，并且实际上，我用ProcessMonitor在生产环境抓取了一段时间Log Writer后，绝大多数的日志写确实在1K及以下。

测试总结：

在尽可能模拟SQL Server IO行为的前提下，我们测试的两块SSD硬盘组成的RAID1表现出了与第一篇测试文章时不同的性能行为。

SSD的特性是不再以物理寻道的形式获取数据，而是电子存储芯片颗粒直接读写，再也没有磁头移动消耗的时间，并且，SSD硬盘的并发读写能力是建立在多线程之上的，在同一时刻的工作绝不会局限于一个颗粒之上，本例我们测试的最大线程为24（测试服务器逻辑CPU数目），也许这是制约这组SSD硬盘没有发挥出最大功效的原因吧。即使这样，我们仍然可以察觉出簇为64KB比4KB时是有优势的。

如果您有不同意见，请提出，我们继续讨论。

手头上没有SAS硬盘的RAID，如果您有兴趣，可以试一下，差别应该会更大一些。

SQL Server 服务器磁盘测试之SQLIO篇（二）,gxlsystem