The latest update to DiskSpd can be downloaded from https://aka.ms/diskspd.
diskspd -w100 -t8 -d60 -o32 -r -b8K -Sh -L -c20G C:\test.dat diskspd -w0 -t8 -d60 -o32 -r -b8K -Sh -L -c20G C:\test.dat diskspd -w100 -t8 -d60 -o32 -si -b64K -Sh -L -c20G C:\test.dat diskspd -w0 -t8 -d60 -o32 -si -b64K -Sh -L -c20G C:\test.dat
What Do the DISKSPD Parameters Mean?
While we’re looking at that set of commands, here’s a quick breakdown:
- -w100 and -w0: means we’re testing writes (100% writes) or reads (0% writes).
- -t8 and -o32: means 8 threads with up to 32 outstanding requests at once.
DISKSPD isn’t CPU-bound at all, and you can use more threads than you have processors.
The more load we throw at storage, the faster it goes – to a point.
- -d60: means the test will last 60 seconds
- -b8K and -b64K: the size of our IO requests in kilobytes.
SQL Server does a lot of random stuff in 8KB chunks,
and we’re also testing sequential stuff in 64KB chunks.
- -r and -s[i]: random versus sequential access.
Many queries jump around randomly in the database, whereas things like backups,
bulk loads, and table scans generally work sequentially. If the optional interlocked (i) qualifier is used, a single interlocked offset is shared between all threads operating on a given target so that the threads cooperatively issue a single sequential pattern of access to the target.
- -L: measure latency statistics.
- -Sh: equivalent -Suw, disable software caching, equivalent to FILE_FLAG_NO_BUFFERING and enable writethrough (no hardware write caching), equivalent to FILE_FLAG_WRITE_THROUGH.
- -c20G: create a file of 20GB. Size can be stated in bytes or KiB/MiB/GiB/blocks.
You’ll notice I’m using a lot of general terms here about how some application patterns work.
Every SQL Server database has its own access patterns – random, sequential, big chunks, small pieces, and so on.
The four test lines you see above are shorthand examples of how some SQL Server IO patterns work.
Check all the command line parameters on the official github repo wiki.