IOBlazer
Release Date: January 10, 2011
IOBlazer is a multi-platform storage stack micro-benchmark. IOBlazer runs on Linux, Windows and OSX and it is capable of generating a highly customizable workload. Parameters like IO size and pattern, burstiness (number of outstanding IOs), burst interarrival time, read vs. write mix, buffered vs. direct IO, etc., can be configured independently. IOBlazer is also capable of playing back VSCSI traces captured using vscsiStats. The performance metrics reported are throughput (in terms of both IOPS and bytes/s) and IO latency.
IOBlazer evolved from a minimalist MS SQL Server emulator which focused solely on the IO component of said workload. The original tool had limited capabilities as it was able to generate a very specific workload based on the MS SQL Server IO model (Asynchronous, Un-buffered, Gather/Scatter). IOBlazer has now a far more generic IO model, but two limitations still remain:
- The alignment of memory accesses on 4 KB boundaries (i.e., a memory page)
- The alignment of disk accesses on 512 B boundaries (i.e., a disk sector).
A very useful new feature is the capability to playback VSCSI traces captured on VMware ESX through the vscsiStats utility. This allows IOBlazer to generate a synthetic workload absolutely identical to the disk activity of a Virtual Machine, ensuring 100% experiment repeatability.
Any 32-bit Windows or Linux system or any 64-bit Windows, Linux, or OSX system should be able to run IOBlazer. On Linux systems, libaio is required.
Simply copy and run the appropriate binary for your OS. Alternately, IOBlazer can be built using the included source code. Further details can be found in the provided README file.
Updates in IOBlazer 1.01:
- Added configurable IO alignment
- Increased the robustness of the trace file parser in the face of spurious lines
- Increased the robustness of the build process by automatically detecting target OS and arch within the Makefile
- In the Windows version, changed the raw access mode from volume to physical drive to avoid unnecessary mount/unmount operations at every test run.
