One of the sorely missing aspects of storage is analyzing and understanding the IO patterns of applications. This article will examine some techniques for performing IO profiling of an application to illustrate what information you can gain.
The really cool part of using strace is that you have a great deal of information at your finger tips. For example you have the amount of data written or read and the amount of time it took to perform a syscall. You can use this information to compute the throughput of each individual write() or read() system call. You can also add the amount of data written or read to produce the total amount of data. In addition, you can count the number of read() and write() system calls in a given amount of time to compute the Read IOPS or Write IOPS. Moreover, you can count the total number of IO syscalls to get the Total IOPS.
There is a great deal you can do with this information including performing a statistical analysis of the results. You can look at the average size and standard deviation size of read() and write() syscalls. You can look at the distribution of the “sizes” in the read() and write() syscalls (i.e. the amount of data in the syscall). You can examine histograms (results as a function of time) for reading, writing, IOPS, movement of the file offset (lseek), etc. In other words – there is a huge number of possibilities you can do with the data.
Let’s walk through the strace output and examine some of the statistics for the IO sycalls. First let’s examine the first write() syscall. The elapsed time is 0.001326 seconds (1326 microseconds). The amount of data written was 397,312 bytes. So the throughput was,
Don’t forget that we are just measuring what the OS gives us from strace. We don’t have any way to measure what is going in the storage system stack using strace (to my knowledge). It is very likely that what we are seeing is the amount of time it took to write the data (0.4 MB) to the system cache or the disk cache – not the time it took to write the data to the drive. But, perhaps most important, we are seeing the amount of time the application took to write the data. Since we are interested in the IO behavior from the perspective of the application then this amount of time is very pertinent to our investigation.
We can do the same computations to the second write():
The total elapsed time for the application is also easy to compute. You just take the difference in the time from the time of the last syscall plus it’s elapsed time (line 33) and the beginning of the fist syscall (line 1). Since the last syscall did not have any elapsed time then it’s just the time for the start of the last syscall:
We can also compute the amount of time for all IO syscalls. This gets a little more involved since we need to add the time for the open(), fstat64(), write(), and close() syscalls. Skipping the open syscalls for files that the application does not specifically open or close, results in the following:
We can then determine how much time was spent doing IO versus everything else:
(0.001419 / 0.005888) * 100 = 24.1%
So for this application, almost 25% of the time is spent performing IO. Since the application only does IO, except for filling up the array, 25% is quite understandable.
The last thing I will examine in this article is the IOPS. The basic definition of Write IOPS is the number of write syscalls in a given amount time. It is usually measured in number of Write IO operationss per second. The same is true for Read IOPS except for read() syscalls. And finally, the Total IOPS includes all IO syscalls.
The Write IOPS is fairly easy to compute. Since the application runs for less than 1 second, you just count the number of write() syscalls to get the Write IOPS.
Write IOPS = 2 IOPS
The Total IOPS is found in a similar manner by just counting the number of IO related operations.
Total IOPS = 5 IOPS
This application is almost as simple as you can get so these IOPS are very, very small.
Understanding the IO profile or IO behavior of your application is almost non-existent yet it is one of the most important things needed when designing a storage system. If you understand how your application(s) is performing IO then you can determine the performance requirements of your storage. How much capacity? How much throughput? How many IOPS? How much lseek capability? How much time is spent performing IO? And on and on. Empirical evidence such as “adding a disk improved throughput by 11%”, can help but it falls short in truly understanding the storage requirements of your application. Moreover, if the requirements aren’t to you liking (or your budget), then if you own the application and have the source, you can modify the application to adjust the requirements.
In this article strace is used as the mechanism to gather the IO system information from the application. Yes, running strace impacts the behavior of the application and if you dump the strace information to the same file system being used by the application, you are impacting the timing behavior. But, to be bluntly honest, there are no other tools to gather IO system information (to my knowledge). In addition, strace does not require the application to be modified to use an independent library for tracing IO syscalls nor does it require that a new library be installed to capture this information (which also impacts IO behavior). Finally, strace is easy to use and can produce some extremely useful information (as we saw).
This article is the first in a series examining the use of strace to gather a great deal of IO statistics about an application. It’s a quick introduction but I hope it shows that you can generate a great of information from simple computations. The example application was trivial but I wanted to show how you go about computing statistics and IO measurements such as throughput and IOPS.
In the next article I will discuss how to use strace for MPI (Message Passing Interface) applications commonly encountered in HPC (High Performance Computing). Future articles will also present tools for processing the strace output files since performing the math for several hundred thousand IO syscalls can get a little tedious (and time consuming).