Microsoft suggested we use diskspd to test our disk performance. Here is the result of 2 sets of test. I have runned them a couple time, for longer interval and at different time so I am sure the result aren't incidental.
According to the documentation about diskspd -Sw disable write-though IO and -Su disable software caching. Let me specify that with or without -Sw, on the first command line, the result are the same letting me know that this flag does not have much impact. From this tool(created and managed by the Windows team), we could conclude the cache (disable with -Su) is ruining disk performance but this does not seem right.
After you download the diskspd.exe executable file, open a command prompt with administrative rights (by choosing "Run as Administrator"), and then navigate to the directory where you copied the diskspd.exe file.
Copy the desired diskspd.exe executable file from the appropriate executable folder (amd64fre, armfre or x86fre) to a short, simple path like C:\DiskSpd. In most cases you will want the 64-bit version of DiskSpd from the amd64fre folder.
In all seriousness, although diskspd is the engine behind Crystal Disk Mark, it stands on its own as a separate tool. Download the executable and unzip it to an appropriate folder. There are going to be three sub-folders:
Often we want to test the storage performance of an exsiting filesystem. To do that, use the -Su flag to bypass the filesystem cache.
Although the specific IOP figures reported will entirely depend on the underlying storage, the diskspd reported number and the number reported from the storage device should be quite close.
Another option is to not read via filesystem at all and use physical device. When we use diskspd with physical device, we bypass the filesystem, so the expected behavior is that buffered (default) and unbuffered (-Su) will return about the same performance because there is no filesystem buffer cache.
When using physical devices. We expect the results from diskspd to be similar to the underlying storage results REGARDLESS of whether caching is enabled or disabled. This is because when we access the disks directly, there is no cache so using -Su has no effect. The results should be very similar.
When using physical devices directly (using the format #) there is no need to use the -Su flag since there is no cache anyway. The figures reported by diskspd should be very close to what is observed at the storage.
Not too long after our discussions, diskspd 2.0.17 was released and it contained the tricks I just explained. Since Ned brought it to my attention, I always referred to this mode as the hel.ya mode because of the example he sent me about how to use it:
So here diskspd will create a very small 2MB file and then issue 64K random IO from 2 threads with 2 outstanding IO for a duration of 60 seconds while disabling the client side cache and leaving the server side enabled and also measuring the latency while the test is running.
Hi, would someone please help me to solve my problem?
I have 2 virtual machine , storage of first vm is sas raid 5, storage of vm 2 is ssd raid 10, i tested them with hd tune and diskspd and the result was this : vm 2 is at least 20 times faster than vm 1, i have my sqlserver on both vms, i run a query on both and the result is like this : vm 1 is twice faster than vm 1.
sorry for my bad english and thanks in advance.
It is a command-line tool, for this reason, we need to open a command prompt with administrative rights and then we navigate the directory where we copied the diskspd.exe. When we execute the diskspd.exe without parameter on the command prompt, it returns version details and all parameter descriptions.
As we can see, diskspd.exe can be executed a variety of parameters but in the following table, we will look at the important ones and we can also find detailed information in Command line and parameters help documentation.
The command diskspd.exe -c1G -b4K -t2 -d60 -a0,1 testfile1.dat testfile2.dat on the other hand creates two 1GB testfiles, sets the block size to 4KB, creates 2 threads per file, sets the cpu affinity to CPUs 0 and 1, and runs the test for 60 seconds.
Running diskspd with the below example command line will generate I/O to evaluate connectivity. The in the command line should be the drive letter of the newly connected volume. To learn how to set up a drive letter for a newly connected volume see Working with Volumes on a Windows Server Host.
The following picture shows you the output from diskspd when executed against the C drive, which uses the LSI Logic SAS controller and where the underlying VMDK file is stored in a vSAN Datastore with a FTT (Failure to Tolerate) method set to 1:
df19127ead