Sorry about the line wraps but I think you can read the output well enough.

There are a few interesting things to note about the strace output. First, the open() syscall is used even for .so libraries (sharable object - dynamic link libraries).

The lines 1 to 25 do a bunch of “setup” work to start the application, allocate memory, read and load any needed functions from any .so libraries.

Finally, on line 26 we get to the point where our application starts to do some IO. Line 26 opens the file and assigns the file descriptor “unit” of 3.

Then line 29 actually writes 397,312 bytes of data to the file and line 30 writes 2,688 bytes to the file. The sum of the two writes is 400,000 bytes which is what we expected given that the test system is 32 bits, we’re using floats, and we have an array of 100,000 elements (4 bytes each).

Finally, the application closes the file on line 31 and the application stops shortly after that line.

You can also see that for the write() syscalls, the first few bits of data that are being written inside the quotations in the strace output.

For this example, the data is binary so the data doesn’t much sense.

But if the data is text or non-binary data, then you might be able to read the first part of the data. Strace does not list all of the data being written to the file.

The very last number, after the equals sign, is the number of bytes actually written to the file descriptor. For this example, there are two write syscalls.

The first one writes 397,312 bytes and the second writes 2,688 bytes.

The total of the fwrite functions is 400,000 bytes (as it should be).

Another interesting observation, and one that I can’t explain, is why the compiler forces the single fwrite command into two write() syscalls.

Through some experimentation, if the number of float elements is set with anything up to 1,024 elements (4,096 bytes) then you will get a single write() syscall in the strace output.

However, for 1,025 elements and up (at least to 1,000,000 elements), you will get two write() syscalls in the strace output.

My only thoughts are that 4,096 Bytes (4KB) is the virtual memory pagesize as well as the sector size on the drive.

I’m sure it has something to do with the virtual memory pagesize but I haven’t been able to determine why (if you have any information please post it!).

Further Analysis of the strace Output

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.

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.

Summary

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).