Installation
Download IOmeter from
iometer.org. I also download the documentation to be sure that I have the updated documentation.
Manual Setup
The drive must be defined on each worker before any other configuration in the IOmeter GUI.
You can only define one drive ("target") per worker.
Set up for 20 workers if the server has that many cores. If you have more cores than that you still don't need to define more that 20 workers in IOmeter.
IOmeter need a storage size to test on. It should three times larger than the complete amount of cache storage in the stack to the drive. On a SAN-drive this gives that the test file might be rather large. If you don't know the cache size and are working on local disks you could start with 40GB.
The maximum disk size is a little tricky as it is measured in number of sectors in IOmeter.
To get from storage amount like in GB to number of sectors you need to know the sector size. On a lot of disks it is 512B but some large disks with rotating platters mights have a sector size on 4KB. The number you can get in PowerShell with the CIM class
Win32_DiskDrive where the attribute BytesPerSector gives the value.
When you have the sector size and know the size you want for maximum size the the calculation can be like this on a 40GB maximum:
(40GB * 1024MB * 1024KB * 1024B) / 512B = 83.886.080 sectors
In the tab "Access Specifications" I chose Default and added it as assigned.
The definition then can be altered by editing the default specification.
The "Transfer Request Size" is changed to the sized wanted for the test, e.g. 64 Kilobytes.
As SQL Server Database Engine mainly works sequential setting "Percent Random/Sequential Distribution" should be set to 100% Sequential. This setting is for some tests set to 100% Random.
A lot of SQL Server storage activity on data i reading, and then the setting "Percent Read/Write Distribution" should be set to 100% Read. This setting is for some test set to 100% Write.
On the tab "Results Display" the setting "Update Frequency (seconds)" should be set for 2 seconds to display the testing in a usefull way.
Start with 12 outstanding I/Os. Justify up and down to get highest bandwidth ("Total MBs per Second (Decimal)") before latency ("Average I/O Response Time (ms)") grows.
Test
A test series could be like this
- Read 8 KB random I/O
- Read 32 KB random I/O
- Read 64 KB random I/O
- Read 256 KB random I/O
- Read 8 KB sequential I/O
- Read 64 KB sequential I/O
- Read 256 KB sequential I/O
- Read 1024 KB sequential I/O. IOmeter changes this entry to 1 MB.
- Write 8 KB random I/O
- Write 32 KB random I/O
- Write 64 KB random I/O
- Write 256 KB random I/O
- Write 8 KB sequential I/O
- Write 32 KB sequential I/O
- Write 64 KB sequential I/O
- Write 256 KB sequential I/O
Measures
Setup a local Performance Monitor to local disk in blg-files.
Measure Logical Disk, not Physical Disk.
Manual Execution
The IOmeter status shows "Preparing Drives" while creating the file. And it will take quite some time. You should plan on a few hours.
After the file is created it is reused for each run om the same disk. Even if the testing parameters are altered.
Let each test run for about ten minutes.
Cleanup
The test file "iobw.tst" is in the root of the drive. When IOmeter is stopped this file can be deleted. The deletion requires administrator rights.
Be nice and clean up after yourself ;-)
Discussion
The IOmeter execution could be automated like I have done before with
SQLIO. But as a manual evaluation is needed for the adjustments on outstanding I/Os it is practically not of much use to build an automated execution.
To be fair I have not discovered the detailed values in handling IOmeter myself. This has been delivered by Michael Frandsen (LinkedIn:
michaelfrandsendk) in other context than this.
Posts
