速度超快的处理器加上Ultra320 SCSI RAID控制器所达到的数据传输率和响应时间给人们留下了印象深刻。
我们最近开始测试基于Intel的Xeon处理器的商用服务器。其中新出现的服务器是IBM xSeries 235 eServer。该服务器支持双Xeon CPU，前端总线频率为533MHz，内存最大可达12GB，内存型号为 ECC DDR266，该服务器内置Broadcom NET-XTREME 千兆以太网接口，LSI Logic 53c1030 Ultra320 SCSI RAID控制器。以及64位133MHz PCI-X扩展槽。该类服务器用于诸如金融建模，数字渲染和地震分析的应用场合，这些计算需要很大的带宽。
我们测试了配置了Maxtor的Atlas 15K Ultra320 SCSI硬盘驱动器的IBM xSeries 235服务器，操作系统为Windows 2003 Server Enterprise Edition和SuSE Linux Enterprise Server (SLES) 8.0，使用服务器内置的LSI Ultra320 SCSI RAID控制器。所采用的Maxtor硬盘的最大数据传输率为75MBps，寻道时间仅为3.2ms，转速为15,000rpm，其每秒I/O次数比Maxtor的10K (10,000rpm)转速的Ultra320 SCSI驱动器还要多45%。
图1：在我们的4驱动器RAID 0卷上的数据流(只读)的结果是：Windows 2003 Server (NTFS)的数据传输量高于SuSE Linux (XFS)。 这主要是Windows使用的异步线程在高端的基于Xeon的系统中发挥了作用，这项测试基于oblDisk 1.0和oblWinDisk 3.0。
15K和10K两种转速的驱动器采用的是Maxtor的第二代Ultra320 SCSI接口。该接口结合了Maxtor的MaxAdapt电路，该电路在放大信号的频率同时过滤噪声，可以动态改善SCSI总线上的信号质量。
Ultra320 SCSI对主要协议进行了改进，以便减少成本，提高性能，可支持高达320MBps的数据突发传输率。Ultra320 SCSI的一个重要功能称为“打包的SCSI”，即在一个连接中传输含有数据和状态信息的同时，还可传输多个命令。相反，Ultra160 SCSI 在同步阶段传输数据，传输率为160MBps，而在稍慢些的异步阶段传输命令和状态信息，而且命令和状态信息局限于每次连接时仅传输一次。结果是Utra320 SCSI最大限度地利用了总线，并使得传输命令的代价达到最小，所以性能更佳。
但是，SCSI控制器中这些性能的改善会带来服务器的性能问题：Ultra320 SCSI的I/O性能提高了，标准的64位的PCI总线却变得拥挤起来，更不用说使用32位PCI总线了。如果你打算享受Ultra320 SCSI所带好处，你需要配置至少带有一个100MHz PCI-X插槽的服务器。
在xSeries 235服务器上安装Windows 2003 Server Enterprise Edition，我们开始测试每个操作系统处理大量I/O的能力。Windows 2003 Server对存储管理有了不少改进，其中最有趣的就是能够在共享卷上，通过卷影复制服务(Volume Shadow Copy Service)进行快照备份。系统管理员可以把创建单个或者多个卷的及时点的副本的工作自动化，且可以立即从这些及时点的档案中恢复文件。
管理员可以用多种方法使用该功能，最简单的就是在管理工具使用新文件服务器管理选项。在该管理控制台中，可以配置为在特定时间间隔或在硬盘暂定工作的间隔，进行影子拷贝。另外，在进行影子拷贝时，可以对总共保留空间的大小进行限制。
为了进行这些影子拷贝，客户系统需要更新Windows Network Neighborhood applet。这个更新把Previous Versions标签加入到共享卷窗口属性中。一旦点击该选项，用户可以看到该硬盘卷的及时点的拷贝列表。通过选择时间间隔，就会打开带有档案文件的窗口，可以象操作其他文件一样打开，拖放这些档案文件。
作为对照测试，我们在同样的服务器上装了SuSE Linux Enterprise Server(SLES)。SLES基于同样的代码，可以用于多种32位和64位架构，从Intel X86到Itanium，Opteron，POWER4，甚至eServer zSeries大型机。
对于Windows 2003服务器的存储子系统的测试，我们运行的是oblWinDisk和oblLoad 基准测试软件。 对于SLES，我们运行的是oblDisk和oblLoad。OblWinDisk和oblDisk测试的是数据传输率，而oblLoad 测试的是同每秒I/O操作次数(IOPS)相关的I/O事务请求处理。
正如我们所预料的，随着读入的数据块尺寸的增大，Windows 2003服务器下的I/O传输量也在爬升。在Linux下,小的数据块通过操作系统捆绑到更大的数据块中，最大可达128KB。其结果是：当读的数据块的大小从2KB增加到128KB时，传输量几乎不变。
图2： 对于传统的TPC1基准中规定的平均响应时间小于100ms这个指标，Linux (XFS)比Windows 2003 Server (NTFS)的测试结果更优，前者可以实现更多的I/O请求次数。测试基于oblLoad v.1.0基准。
通常情况下，在Linux和Windows下的两条数据传输率测试曲线在读数据块大小达到64KB时汇合。我们的测试中，两种操作系统下使用的都是LSI Logic Ultra320 SCSI控制器，当读入的数据块的大小为16KB时，Windows环境下的I/O传输量开始超过Linux。当读入数据块大小为64KB时，Windows 2003 Server下的数据传输量比Linux超出33%。重要的是，大多数程序使用的是8KB的数据块的读入尺寸。通常在Windows环境下，仅在使用诸如备份软件或者内部的数据库时，才使用大的数据块尺寸。
Windows环境下的性能更优的原因归功于Windows进行file I/O的工作。不同于Linux的捆绑请求的做法，Windows能够响应所有的请求，之后异步地等待它们所请求数据的返回。
这个概念可以通过oblDisk基准测试得到模拟，该软件把文件分区，使用单独的线程来并行地读入每个区的数据。当使用了4个线程时，Windows下的数据传输量一直等到数据块大小超过32KB时，才超过Linux。
对于15K的Maxtor硬盘来说，一个重要的指标是其快速的3.2ms的寻道时间。在我们的oblLoad I/O 负载基准测试中，有这样出色的结果，这个指标起了关键作用。
通常这种测试是在事务处理环境中测量实现数据库模式的I/O的请求的次数的，这对Linux来说并不适合，因为以往的Linux内核并不专门支持异步I/O，而Windows则支持。
在oblLoad基准测试中，后台线程处理时发送的是自己的单独的8KB大小的数据块请求，这个方法模拟了存取关系数据库的模式。这个过程持续到平均存取时间超过100ms，100ms是TPC1基准测试的门槛。oblLoad的测试结果可以表示为每秒总共的I/O次数同总共I/O相关进程的数量之间的关系，或者表示为响应时间同每秒处理的I/O次数之间的关系。
随着更多I/O处理线程的加入，系统完成更多I/O请求的能力取决于数据缓存大小和线程负载平衡能力。
对于LSI Logic控制器，在SLES上，我们能够发送出250个模拟用户在线时的2,000多个IOPS，这个数字是我们的Ultra160 SCSI参考子系统的两倍多。令人惊奇地是，这个数字也比Windows 2003每秒能够处理的I/O次数多。尽管如此，Windows 2003 Server在这些测试中的结果更胜一筹，在Windows 2003中，我们测试结果表明：在少于8ms内，Windows可以处理更多的I/O次数。对于8ms的响应时间， Windows 2003每秒处理的I/O次数要比Linux多40%。
