测试技术分享：存储性能测试漫谈

测试积点老人

对于存储性能测试，一般有两种方法：
　　1. 使用业内比较认可的性能测试工具，比如IOMeter、fio、iozone等。这类工具一般是开源的，应用范围很广泛，使用它们的一个好处是可以快速和其他存储产品做横向对比。哪怕大家是在不同时间、不同地点、不同环境测试的，但只要参数设置差不多，就可以拿来简单对比（如果要做完整对比，必须放在同样的环境中测试）。不足之处是它们只能按照预定义的模式机械测试，大多数情况下无法真实反应实际应用环境的IO模式。
　　2. 直接在真实的应用环境中进行性能测试。这种方法测出来的结果，针对特定的场景，具有权威的参考性。不足之处就是搭建环境可能比较麻烦，每个应用的依赖环境都不一样。即使是同样的存储设备，在不同的应用场景，其性能差异也很大。所以这种方法能反应存储产品在特定场景下的实际性能，但有时候并不能确定存储产品的普遍性能。
　　使用同样的存储设备，同样的硬盘，当如下条件变化时，性能差异可能会很明显。
　　1. 读和写。理论上，机械硬盘的顺序读写性能差不多。但在不同的场景，同样硬盘的读写性能是有差异的。因为写数据的时候，缓存的作用更大，所以写的性能可能更好。但如果使用RAID5，因为写数据有写惩罚，所以在其他条件相同时，读的话性能更好。SSD的读写参数天生就不一样，因为写数据会引起块擦除，所以往往读更快，尤其是随机读。
　　2. 顺序IO和随机IO。对于机械硬盘，毫无疑问，顺序读写比随机读写快很多，因为顺序读写少了很多寻道时间，其速度比随机读写高出1到2个数量级。所以，传统的存储需要使用缓存算法（包括按扇区地址的排序以及预读等）来减少寻道时间，提高性能。对于SSD，顺序读写和随机读写差别不是那么大，但是顺序读写一般来说会比随机读写快。实际应用中，纯随机读写很少，即使在文件系统中拷贝大文件，也有一些相对随机的操作，比如修改元数据，跳过一些被占用的扇区等。所以，如何模拟应用程序的随机度，是一个比较头疼的问题。
　　3. 块大小（block size）。如果单次IO写入的数据块比较大，比如超过了1MB，性能显然比较好。即使是机械硬盘纯随机写入1MB也如此——单个数据块往往是一次性提交给驱动的，每个块内部的数据一般也是连续的。每秒只需要少量的IO能过去，就能获得较大的带宽，因为带宽＝IO大小*IO数，IO数虽然不多，但IO平均大小较大。但也有例外。如果把块大小设置成很大（比如1GB），在系统里面肯定会被拆分成较小的IO发下去，所以性能不会有进一步改善，在应用程序不够完善时反而会导致额外的问题（比如直接就给分配了1GB的内存导致内存有可能不足）。即使前面说的1MB的IO，在很多系统中，也可能会被拆分成2个或者几个IO发下去。如果是顺序读写，4KB的小IO，在[url=]操作系统[/url]内部也可能会被合并成大的IO，所以这种情况下，性能不会太差，但合并IO等步骤本身需要消耗资源，所以性能也不会太好。需要注意的是，有些时候，评判性能标准不是按读写带宽来看，而是按照每秒的IO数（IOPS）来看。显然，块大小的设置就比较难提高IOPS的值了。
　　4. 缓存的影响。当读写缓存比较大时，性能显然会好一些。尤其是进行随机写测试，在写缓存比较大时，刚开始的性能值会非常大（其实就是写到内存的速度），到后来一下子降下来。因此，为了避开缓存的的影响，有时候需要测试direct IO。但在大多数应用场景下，缓存都是需要使用的，我们得了解在缓存起作用的情况下的性能，同时又要跳开刚开始测试阶段的不稳定性能值，那我们可以设置相应的时间参数，不把最开始的一段时间的性能值统计进去。IOMeter的Ramp Up Time就是为这个准备的。有人拿同样的配置测试随机读写，两次测出的值大不一样，其原因就有可能是没有把这个原因考虑进去。即使设置了Ramp Up Time，但其值太小，在缓存还没有写满的时候其时间就到了，也会统计得不准确。
　　5. 同步IO和异步IO。同步IO是发一个IO，等确认完成之后，再发下一个IO。这是一个串行的过程。异步IO是发了一个IO，还没有完成，就发下一个IO，IO的处理过程是异步的。显然，异步IO的性能一般会好一些。IOMeter和fio等都能对它们进行测试。IOMeter有一个“# of Outstanding I/Os”的参数，用于设置可以同时发的异步IO的个数。如果要测试出比较好的性能，一般要用异步IO。
　　6. 其他影响因子。太多了，无法一一列举。比如多线程、机械硬盘的外圈和内圈等。现在的机械硬盘内部结构很复杂，扇区的物理排布和硬盘的固件有关，但一般可以简单认为，机械硬盘的开始部分（扇区地址较小部分，或者简单认为是外圈）比结尾部分（扇区地址较大部分，或者简单认为是内圈）的速度要快。
　　因为有如此多的影响性能的因素，所以，也需要测试工具要提供众多参数来进行设置，以便精准地测试性能的原因。但实际的应用场景可能更复杂，有可能一会儿是大块的顺序读写，一会儿又变得更随机。如果我们能够精准预估应用程序读写存储的模式，理论上也可以用IOMeter等工具来模拟，无非是把配置写得比较复杂而已。但有时候很难预估它的读写模式，所以采用实际的应用环境更具有性能参考意义。因为实际应用环境搭建麻烦，所以，有时候会自己写一些测试工具，尽可能模拟应用场景，然后以比较简单的模式来进行测试，可以有更高的测试效率，以便不断改进系统。