|
Figure 10 – Synchronous unbuffered overhead comparison of NT4SP3, NT4SP6, and Win2K
|
| bet | 19/47 | | Sana | 30.03.2021 | | Hajmi | 1,33 Mb. | | #13789 |
Figure 10 – Synchronous unbuffered overhead comparison of NT4SP3, NT4SP6, and Win2K. Although basic and dynamic volumes under Windows 2000 both attain similar throughput performance, dynamic volumes have a higher processor cost.
Windows 2000 SCSI I/O Performance
Having compared NT4SP6 with Win2K on the old hardware, we move on to Win2K on the new hardware (see Table 5): a dual 733MHz Pentium III processor machine with 10K RPM disks.
Windows 2000 SCSI Random I/O
We first look at random IO performance. Although this paper is primarily focused on sequential I/O, no discussion of the IO subsystem would be complete without some discussion of random I/O.
The Quantum Atlas 10K disks showed good unbuffered random IO performance. Both basic and dynamic volumes had the same results. When we increased the number of disks, the number of IOs per second increased linearly with additional drives.
We used SQLIO to randomly read 8KB blocks from files that each filled an 18GB Quantum SCSI disk. Figure 11 shows that as the request depth increases, the driver and the disk drive are able to optimize the arm movement in order to service the requests more efficiently. One and two-deep requests show the same number of IOs per second. This is because at one deep, the accesses are random. At two-deep, as the first request comes in and the drive begins to service it, the second request also arrives. Since the drive is already servicing the first request, and must commit to the second request before it is given the third request, the drive is unable to optimize the movements of its arms so it achieves only one deep performance. Beyond two-deep requests, the disk is able to optimize by permuting the order requests are serviced, and so the IO rate increases.
With FS buffering, random IO performance, like sequential IO performance, is independent of request depth because the file system is buffering the requests. The file system serializes multiple read requests into one-deep queue of requests for a volume, and the lazy-writer thread also has only one outstanding request. FS buffering improved read performance, but lowered write performance. With FS buffering, the number of IOs per second on reads improved by a factor of two compared to a one deep read. The disk is spinning at 167 revolutions per second, and the disk is performing 220 reads per second (see Figure 11). So, it seems that the reads are being sorted and achieving about 1.3 8KB IOs per revolution. Buffered random writes per second of about 110 IOps is comparable to the 1-deep unbuffered random write throughput (see figure 11). Figure 11 doesn’t show the high the fact that each buffered random write is actually a 64KB random read and then an 8KB write. When a buffered write request is received, the cache manager memory maps a 256KB view into the file. It then pages in the 64KB frame continuing the changed 8KB, and modifies that 8KB of data. This means that for each buffered random write includes one or more 64KB reads. The right side of Figure 11 shows this 100% IO penalty.
|
| |
