Tuning an Application

Typically, you can only tune applications that you are developing. Applications purchased for your system cannot be tuned in this manner, although there is usually a facility to correspond with the application vendor to report poor performance.

If the application is primarily spending its time in user space, the first approach to take is to tune the application to reduce its user time by using the pixie(1) and prof(1) commands. See the respective reference pages for more information about these commands. To reduce high user time, make sure that the program:

• makes only the necessary number of system calls. Use timex -s to find out the number of system calls/second the program is making. The key is to try to keep scall/s at a minimum. System calls are those like read(2), exec(2); they are listed in Section 2 of the reference pages.

• uses buffers of at least 4K for read(2) and write(2) system calls. Or use the standard I/O library routines fread(3) and fwrite(3), which buffer user data.

• uses shared memory rather than record locking where possible. Record locking checks for a record lock for every read and write to a file. To improve performance, use shared memory and semaphores to control access to common data (see shmop(2), semop(2), and usinit(3P)).

• defines efficient search paths ($PATH variable). Specify the most used directory paths first, and use only the required entries, so that infrequently used directories aren't searched every time.

• eliminates polling loops (see select(2)).

• eliminates busy wait (use sginap(0)).

• eliminates system errors. Look at /var/adm/SYSLOG, the system error log, to check for errors that the program generated, and try to eliminate them.

• groups its subroutines together. If often-used subroutines in a loaded program are mixed with seldom-used routines, the program could require more of the system's memory resources than if the routines were loaded in the order of likely use. This is because the seldom-used routines might be brought into memory as part of a page.

• has a working set that fits within physical memory. This minimizes the amount of paging and swapping the system must perform.

• has correctly ported FORTRAN-to-C code. FORTRAN arrays are structured differently from C arrays; FORTRAN is column major while C is row major. If you don't port the program correctly, the application will have poor data locality.

There are a few other things you can do to improve the application's I/O throughput. If you are on a single-user workstation, make sure that the application:

• gains I/O bandwidth by using more than one drive (if applicable). If an application needs to concurrently do I/O on more than one file, try to set things up so that the files are in different file systems, preferably on different drives and ideally on different controllers.

• obtains unfragmented layout of a file. Try to arrange an application so that there is only one file currently being written to the file system where it resides. That is, if you have several files you need to write to a file system, and you have the choice of writing them either one after another or concurrently, you will actually get better space allocation (and consequently better I/O throughput) by writing these files singly, one after another.