| Using IOzone to analyze client side of NFS Don Capps (don.capps@hp.com) Tom McNeal (trmcneal@comcast.net)
IOzone is a useful benchmark tool for analyzing file system performance, which can run on several different platforms, including Linux,hp-ux, Solaris, and so on. It uses file system IO as its primary test method, using a set of file IO requests to represent the performance of the tested system, these IO requests from small files to large files, using different record sizes, implemented a large number of different file access modes. It also allows the test administrator to modify system test parameters that affect the system's response to the size and access patterns of the different accessed files, in order to illustrate the system problems that may not be apparent or may have significant differences between platforms.
In addition to testing the local file system, IOzone can be used to analyze the performance of clients in an NFS client/server environment by using an NFS mounted file system as a target for a set of IO requests. This article discusses the use of IOzone as a profiling tool for NFS clients. It includes a complete set of IO requests, possible options for different system responses, and possible processing of output data that best describes the behavior of the system. In addition, it will discuss general system parameters in order to better understand the system's response to test requests.
Finally, please note that IOzone, along with the accompanying documentation, can be downloaded from the http://www.iozone.org.
File System IO Request
Test execution of File IO selects a wide range of file sizes, default from MB to 512MB, and uses record sizes from 4KB to 16MB. Whether it's a file or a record size, increments are twice times as simple as each time the previous value was used. If you have special requirements, you can also increase the file size to an optional larger value so that you can test the large file system supported by the 64-bit platform. Please note that the word "test", which is used in this article and in the IOzone document, refers to a single type of access--for example, sequentially, from the head of the file to the end of the file--to the execution of all files, the size of which is given in the command line. When IO is performed on each file, it may use the following access modes:
• Sequential read/write-many records will be written to a new file and read from an existing file, from the header of the file to the end of the text.
• Sequential Rewrite--many records will be rewritten to an existing file, from the file header to the end of the file.
• Sequential reread-re-read the records of recently read files, from the file header to the end of the file. This usually results in better performance than normal reading, due to the presence of cached data.
• Rewind read-reads records from the end of the file to the header of the file. A few operating systems optimize file access based on this pattern, and some applications, such as MSC Nastrans, often do the same.
• Random Read/write-writes and reads records at random offsets.
• Rewrite Records-a single record will be rewritten to an existing file, starting with the file header.
• Stride Read-Reads a record at a specific constant interval, from the file header to the end of the file.
fread/fwrite--calls the Fread () and fwrite () functions to write a new file and read from an existing file, from the file header to the end of the file.
freread--calls the Fread () function on a file that has recently been read.
frewrite--calls the Fwrite () function on an existing file.
pread/pwrite--tests the performance of Pread () and Pwrite () on systems that support these system calls. <?xml:namespace prefix = o ns = "Urn:schemas-microsoft-com:office:office"/> |
Note that it is important to limit the size of the buffer cache to the maximum file size when running tests under normal conditions, so that you can see the effect of the cache misses when you test. Of course, this has nothing to do with memory-mapped files, but note that when you look at the test results, you may see other cache effects on performance, in addition to buffer cache, when performing IO requests under those cache size limits. They include the processor cache and level two memory cache, and buffer cache. Ensuring that larger file sizes are larger than these limits can accurately describe the impact of cache hits and misses.
Standard settings for NFS clients
The usual configuration for analyzing NFS clients using IOzone includes the following features:
IOzone is executed from a local directory.
• File IO is limited to files in NFS mounted directories
• Empty client caches ("-u Mountpoint") between two Tests through file system uninstallation and re-hanging
• Measure commit time in NFS V3 ("-C") through file shutdown time
• File size, from MB to 512MB, using record size from 4KB to 16MB ("a")
• When the file size exceeds 32MB, the record size will have a lower limit of 64K. This restriction can be removed by "-Z"
• In addition to the above limitations, all record sizes are used for files that can contain them (for example, 64K files can be tested with a record size of 4 K to 64K, doubling the size of each iteration)
• Reports will be generated in Excel spreadsheet format ("-R")
The format of the Excel spreadsheet is used to generate graphics images to the specified file ("-B filename").
• The results of the standard output are written to a local file.
Assuming the/mnt/foo is an NFS mounted directory, and the local directory is mounted locally, the IOzone command to complete the above situation is as follows:
./Iozone–azcr–u/mnt/foo–f/mnt/foo/testfile–b Exceloutput.xls > LogFile
System-Level differences
Many differences can be generated by testing parameters that reflect the system-level characteristics of the client.
These differences can be used as variants in the data collection process other than standard operations to analyze the impact of client capabilities on the system level, especially when analyzing SMP customers. These differences include:
• Processor affinity for all threads/Processes ("-P #")
• Limit the minimum number of processes ("L n")
• Processor Cache Empty ("-P")
CPU cache size and cache line size ("-s size" and "-l size")
• Remove "stonewalling", an intrinsic feature of a iozone ("-X")
