Iometer is an open source tool originally developed by Intel that remains the simplest and best means of generating load on a system for performance analysis. Because of minute fluctuations in the in-guest timers many in-guest benchmarks are unable to produce accurate results. We at VMware have used Iometer for years and find its results to be accurate in most situations. But see the disclaimer below for a word of caution.
Figure 1. Iometer with disk targets tab selected.
Figure 1 shows the topology and disk target tab for a particular VM. As the manager only has one host visible beneath it and only one worker is present on another host, you can tell that this is a single server with only one processor. Had Iometer been started on a 4-way box, four workers would be visible. As the UI remains operational, dynamo workers can be connected from other hosts to drive load across multiple VMs that may be on multiple servers.
Configuring the Test
For all Iometer tests, under "Disk Targets" always increase the "# of Outstanding I/Os" per target. When left at the default value of ‘1', a relative low load will be placed on the array. By increasing this number some the OS will queue up multiple requests and really saturate the storage. The ideal number of outstanding IOs can be determined by running the test multiple times and increasing this number all the while. At some point IOPS will stop increasing. Generally an increase in return diminishes around 16 IOs/target but certainly more than 32 IOs/target will have no value due to the default queue depth in ESX. See Storage Queues and Performance for more information on queues. In Figure 1 you can see that "# of Outstanding I/Os defaults to 1."
When choosing the system to test in the topology frame, the "Disk Targets" tab will provide options as to the storage target. The options here include formatted disks (yellow) or unformatted disks (blue). In the former case Iometer address the storage through the OS's file system (FS). In the latter, direct calls are made to the hardware without using a FS. Storage specialists are usually more interested in just the hardware so evaluation of unformatted LUNs (blue) is preferable. There is some cost of virtualizing the OS's interface to the disk through the FS so formatting the disk with the correct FS and testing the yellow target can be helpful. Figure 1 shows two testable drives: the yellow-iconed C drive on which the OS was installed and the blue-iconed unformatted drive that is preferable for benchmarking.
Always make certain that the "maximum disk size" in the "Disk Targets" tab is larger then the available memory! For instance, when testing a formatted disk, setting the maximum size to 200,000 sectors (or 100 MB) could be cached by the guest OSes in a VM provided 1 GB of RAM. In this case all Iometer calls to storage will be intercepted and cached by the guest, host, or storage cache. Setting the disk maximum disk size to a number at least four times greater than the memory available in the largest cache will avoid caching.
Under the "Access Specifications" tab, choose a workload that matches the most interesting profile. Real workloads that are dominated by database performance often randomly read and write small, fixed-size block IO. SQL Server on Windows, for instance, uses 16K blocks, 66% read (which implies 34% write), and 100% random (thus 0% sequential). Exchange 2007 uses a similar profile but with an 8K block size. Oracle on Linux has flexibility to use the block size set when the file system was created. Depending on the DB specialists needs, this can range from 2K to 64K but will again be random with a 2:1 read-to-write ratio. Note: you can approximate this Linux performance on a Windows guest but do not run Iometer on Linux (see "Iometer On Linux" below.)
|Application||Block Size||Randomness||Read/write Ratio|
|Exchange 2003||4K||80%||60% read (40% write)|
|Exchange 2007||8K||80%||55% read (45% write)|
|SQL Server||16K, 64K||100%||66% read (34% write)|
Table 1. Example Iometer profiles.
Note the number of workers that has been specified in under the manager. This will default to one worker (thread) for each physical or virtual processor on the system. In the event that Iometer is being used to compare native to virtual performance, make sure that the worker numbers match! For instance, the work count will be one on a UP VM but four for the same native measurements if the system is quad-core. Correct the native worker count by detaching workers.
Before invoking the test, be aware of the potential impacts of data alignment. VMware has demonstrated substantial differences in performance based on alignment of data on storage arrays in our partition alignment paper. Make sure that partitions and virtual disks have been created by Virtual Center to guarantee that the partitions and files are properly aligned.
Disclaimer (or: When Not To Trust Iometer)
As discussed in Time-based Measurements in Virtual Machines, the hypervisor may introduce some inaccuracy to in-guest time measurement. The likelihood of measurement error increases as the server's load increases. Generally servers that are using less than 30% of their available CPU resources can be trusted. In the event that a large VM on a small server is driving all CPUs to high utilization, Iometer results may suffer from some inaccuracy. This is rarely the case with Iometer runs.
Analyzing the Results
As mentioned above, the results provided by Iometer tend to be trustworthy. But for unimpeachable results use the analysis techniques provide by VMware. See the Performance Monitoring and Analysis that's already been dedicated to this subject.