Field
|
Description
|
MB/s
|
I/O throughput in MB/s
|
IO/s
|
I/Os per second
|
Operation
|
Specifies reading or writing (read/write)
|
BlockSize
|
Request size in KB
|
OutstandingIOs
|
Depth of asynchronous I/Os (0 = Synchronous)
|
Buffering
|
0 and Y - File system and controller caching
S –File system caching only (FILE_FLAG_WRITE_THROUGH)
H – Controller caching only (FILE_FLAG_NO_BUFFERING)
N – No caching (FILE_FLAG_WRITE_THROUGH | FILE_FLAG_NO_BUFFERING)
|
NumThreads
|
Number of threads
|
Time
|
User specified time to run
|
FileSize
|
Size of the file being read/written in KB
|
Clock(s)
|
Actual amount of time the test took. Used for calibration purposes.
|
User(ms)
|
Total user mode processor time as reported by GetProcessTimes()
|
Kernel(ms)
|
Total kernel mode processor time as reported by GetProcessTimes()
|
Time Stamp
|
Time and date the test was run
|
Comment
|
String containing a user specified comment. (no commas allowed)
|
|
Table 8 – The format of the SQLIO trace file, a comma separated values (CSV) file.
|
cacheflush is a simple program which does a buffered read of a file and then quits. It measures throughput and processor consumption, and outputs a tracefile in the same format as SQLIO. In earlier tests, we often saw erratic measurements that would alternate between throughputs higher than the maximum throughput of a drive to throughputs below. This was because each test was somewhat dependent upon those before it. The results were thrown off since the system was sometimes able to retrieve part of the file from cache. Our solution to the problem was to fill up the cache using buffered reads from a scratch file. As cacheflush read in the scratch file, the FS buffer was cleaned of any lingering data from the previous test. After cacheflush was run before each buffered test, the erratic measurements disappeared.
Tests were automated using batch files generated by a program named cmdgen. cmdgen takes as its input the environmental variable sqlio_note which contains comments about the current test target. It then outputs a batch file containing multiple calls to SQLIO varying the arguments along with appending information about buffering and synchronism.
We measured the system memory bus using memspeed. memspeed has eight different tests by which it measures the memory bus bandwidth. 10MB is read, written, or copied for each test. In order to calibrate the instruction overhead, before each test a null test was run where no actual reads or writes took place. This instruction overhead is then subtracted from each subsequent test’s time. Reads and writes are measured using two methods: the first method read and wrote 64 bits at a time using doubles. In the read case, the 10MBs are read from memory into a register double. In the write case, the register double is repeatedly written to main memory. The second method used the file system calls WriteFile() and ReadFile() to read and write 64KB at a time. A cached file was created using FILE_FLAG_DELETE_ON_CLOSE and FILE_ATTRIBUTE_TEMPORARY. In the read case, bits were read from this cached file into a 64KB buffer. In the write case, bits were written from the buffer into the cached file. The last test used memcpy() to copy data between two 10MB buffers. On multiprocessor machines, the double read/write tests and the memcpy() test were rerun with multiple threads. The number of threads was equal to the number of CPUs.
memspeed was also used to measure the SCSI, IDE, and PCI bus saturation points by reading a small amount of data on a disk repeatedly using two-deep requests. On the first read, the drive must access the disk in order to fulfill the request. This data is then placed in the drive cache. On subsequent requests, the drive can fulfill the request straight from its cache without going to disk. Tests were run on 1 to 4 disks. This allowed us to measure the burst throughput of single and multiple drives, along with quantifying throughput limitations of the SCSI, IDE, and PCI buses.
The programs we used for workload generation and measurement are available online, along with the raw test results, at http://research.microsoft.com/BARC/sequential_IO/
|
