The Operating System

The addition of Microsoft NT to the list of Informix-supported operating systems means that we can no longer just assume that an Informix application is running on UNIX. Currently, most large Informix databases are running on UNIX, but the NT systems are making inroads into what used to be strictly UNIX territory.

Most operating system tuning will be on UNIX systems, mainly due to the fact that NT is not easily tunable. On NT, the database will either run or it will not. There's not a lot of area in between.

UNIX is totally different. UNIX is the only major operating system that allows you to completely recompile the OS kernel in order to change operating system parameters. In fact, the process of creating a new kernel is actually recompiling and relinking the operating system.

If your target system is UNIX, you'll need to verify that the kernel was relinked with the proper parameters. Kernel tuning is done differently in different flavors of UNIX. If the system has a system administrator, consult with him and get him to relink the kernel for you. If not, go to your manuals and be sure that you understand the process.

If you are relinking the kernel, be sure that you save a copy of the current (working) version of your kernel. Also, be sure that you know how to boot up under the old kernel as well as under the new one.

Read the Release Notes

The release notes for your version of Informix will be found in the $INFORMIXDIR/release directory tree. With the implementation of global language support, there may be subdirectories under the release For example, for a system running U.S. English, the release notes may be found in /usr/informix/release/en_us/0333. Whenever you are familiarizing yourself with a new Informix installation, always go through all of the files in the release notes.

The release notes will contain the most recent information about your particular port of Informix. The files containing kernel parameters will be named something like "ONLIN*." The correct file will usually contain semaphore parameters, shared memory parameters, process parameter, and information about whether various parameters are supported under your current release. You'll also often find information about such features as forced residency, kernel async I/O (KAIO), processor affinity, processor aging, and supported interface/protocol combinations. You may also find information about operating system patches that should be present on your system. If these patches are not in place, make sure that you manage to have them installed.

Note that these recommended kernel parameters come from the development group that actually did the port. Their parameters are parameters that have worked on their development machine. There is no guarantee that these parameters are the most efficient or the most optimal parameters. The only guarantee is that someone, somewhere got an Informix server to work using them. They are a place to start, not commandments chiseled into stone.

Inspect the Kernel

Once you know the required kernel parameters, check your current kernel's parameters. This usually requires root access to the system. If you have a system administrator, have her do the inspection and/or relinking.

Consider Other Applications

Unless the Informix server is the only application on the hardware, you must consider all of the other applications that are running on the server. If they have special shared memory or semaphore requirements, you will need to consider their kernel requirements in addition to Informix's kernel configuration requirements.

There are no hard and fast rules here. I generally try to err on the side of too many kernel resources rather than too few. Sometimes this liberal approach may lead to a bloated kernel. If the kernel grows unnecessarily large, its performance may be less than optimal. Always compare the size of your "before" and "after" kernels. If your "after" kernel is significantly larger than the "before" version, you may find that you've slowed the system down rather than sped it up. Kernel tuning is somewhat of a black art. It may take a bit of trial and error to get it right. You'll probably never be 100 percent sure that the kernel is right. For many of us, just having it right enough so that the database doesn't crash will be good enough. Look at kernel tuning as a go/no-go situation. It either works reliably or it doesn't. If it works reliably and without glaring evidence that there are problems, it is probably good enough to run in production. If you need to spend your time tweaking something, you'll find that you get more "bang for the buck" by concentrating on other areas such as indexing and analysis of your SQL code.