上次放出了一篇文章，针对磁盘卷簇大小默认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及以下。
5、作者的第5条认为SAN存储，由于有巨大的缓存，并且优化了读写机制，所以读写的差距不是很大，所以建议只使用Random作为测试方式，这一点，我决定不苟同于作者，仍然按照Data和Log的读写特性来进行测试，随机和顺序都会照顾到。
综上所述，根据个人知识点，测试要点总结如下：
1、我们首先建立两个Para.txt文件，一个Thread为逻辑CPU数目24，另外一个Thread我们设置为1，对应于上图中“使用线程数”中的内容，另外，我还将测试文件testfile.dat的大小调整为了5000M。
本次我为了避免误差，仅使用同一组RAID1来完成这三组簇分别为4KB/8KB/64KB大小的测试。
ParamMT.txt
D:\testfile.dat 24 0x0 5000
ParamST.txt
D:\testfile.dat 1 0x0 5000
2、以下为测试脚本，我们将-o参数从1开始增加，然后以翻倍的形式，测试出IO的最大能力。
echo ****** Read Tests *****
echo ******random_R_8KB**********
sqlio -kR -s300 -frandom -o1 -b8 -LS -BH -FparamMT.txt > Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o2 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o4 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o8 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o16 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
echo ******random_R_64KB**********
sqlio -kR -s300 -frandom -o1 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o2 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o4 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o8 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o16 -b64 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
echo ******random_R_512KB**********
sqlio -kR -s300 -frandom -o1 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o2 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o4 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o8 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kR -s300 -frandom -o16 -b512 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
echo ******random_W_8KB**********
sqlio -kW -s300 -frandom -o1 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o2 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o4 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o8 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o16 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
echo ******random_W_256KB**********
sqlio -kW -s300 -frandom -o1 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o2 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o4 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o8 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -frandom -o16 -b256 -LS -BH -FparamST.txt >> Cluster_4KB_test.txt
timeout /T 5
echo ******sequential_W_1KB**********
sqlio -kW -s300 -fsequential -o1 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o2 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o4 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o8 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o16 -b1 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
echo ******sequential_W_8KB**********
sqlio -kW -s300 -fsequential -o1 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o2 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o4 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o8 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
sqlio -kW -s300 -fsequential -o16 -b8 -LS -BH -FparamMT.txt >> Cluster_4KB_test.txt
timeout /T 5
- 先说第二个直方图，我们可以看到，在顺序写时，三种簇大小下几乎是没有差别的；
- 第一个直方图，在随机读取64KB和512KB时，簇为4KB相比其它两种情况是有优势的；其它读写情况下，还是簇为8KB和64KB时占据优势。
- 我们上面已经说过，SQL Server的随机读，绝大多数还是以8KB为单位的，从这点来看，依然还是簇为8KB和64KB比簇为4KB在全局来讲，要占据优势，而簇为64KB比8KB的优势，是微乎其微的。
测试总结：
在尽可能模拟SQL Server IO行为的前提下，我们测试的两块SSD硬盘组成的RAID1表现出了与第一篇测试文章时不同的性能行为。
SSD的特性是不再以物理寻道的形式获取数据，而是电子存储芯片颗粒直接读写，再也没有磁头移动消耗的时间，并且，SSD硬盘的并发读写能力是建立在多线程之上的，在同一时刻的工作绝不会局限于一个颗粒之上，本例我们测试的最大线程为24（测试服务器逻辑CPU数目），也许这是制约这组SSD硬盘没有发挥出最大功效的原因吧。即使这样，我们仍然可以察觉出簇为64KB比4KB时是有优势的。
如果您有不同意见，请提出，我们继续讨论。
手头上没有SAS硬盘的RAID，如果您有兴趣，可以试一下，差别应该会更大一些。
