The limiting factor for a single program

Edit online

If you are the sole user of a system, you can get a general idea of whether a program is I/O or CPU dependent by using the time command as follows:

# time cp foo.in foo.out

real    0m0.13s
user    0m0.01s
sys     0m0.02s

Note: Examples of the time command use the version that is built into the Korn shell, ksh. The official time command, /usr/bin/time, reports with a lower precision.

In the above example, the fact that the real elapsed time for the execution of the cp program (0.13 seconds) is significantly greater than the sum (.03 seconds) of the user and system CPU times indicates that the program is I/O bound. This occurs primarily because the foo.in file has not been read recently.

On an SMP, the output takes on a new meaning. See Considerations of the time and timex commands for more information.

Running the same command a few seconds later against the same file gives the following output:

real    0m0.06s
user    0m0.01s
sys     0m0.03s

Most or all of the pages of the foo.in file are still in memory because there has been no intervening process to cause them to be reclaimed and because the file is small compared with the amount of RAM on the system. A small foo.out file would also be buffered in memory, and a program using it as input would show little disk dependency.

If you are trying to determine the disk dependency of a program, you must be sure that its input is in an authentic state. That is, if the program will normally be run against a file that has not been accessed recently, you must make sure that the file used in measuring the program is not in memory. If, on the other hand, a program is usually run as part of a standard sequence in which it gets its input from the output of the preceding program, you should prime memory to ensure that the measurement is authentic. For example, the following command would have the effect of priming memory with the pages of the foo.in file:

# cp foo.in /dev/null

The situation is more complex if the file is large compared to RAM. If the output of one program is the input of the next and the entire file will not fit in RAM, the second program will read pages at the head of the file, which displaces pages at the end. Although this situation is very hard to simulate authentically, it is nearly equivalent to one in which no disk caching takes place.

The case of a file that is perhaps just slightly larger than RAM is a special case of the RAM versus disk analysis discussed in the next section.