00206: Fine tuning Xenix/Unix

Title:

Fine tuning Xenix/Unix

Description:

We often get requests for help in improving a system’s performance, and generally the focus is on tuning Xenix/Unix relative to using BBx and applications developed using BBx. It would be wonderful if we could just pass along the magic numbers, but unfortunately, it’s not that simple. Each Xenix/Unix system is a little different, so there aren’t any universal answers. The tuning for each system is highly dependent on the specific components that make up the system and how these are required to interact. Tuning of a Xenix/Unix system is extremely dependent on numerous variables, such as: 

– individual application, its programming and resource requirements, optimal sizing of cache buffers 
– resources available on a system 
– the particular implementation of Xenix/Unix for that system 
– the resource requirements for each of the tasks running on the system at a given point 
– the number of users 

We have tried in the BBx documentation to give some general guidance as to the areas where BBx and the computer system on which it is running interact. This tells us where some form of tuning relative to BBx might be appropriate. It should be emphasized however, that the effect of the language pales in significance with respect to the way the language is used in the application. (By the way, this is the reason why language performance benchmarks are often of somewhat dubious value.) For these reasons we cannot give specific answers, but we can offer some of the general guidelines that we use internally. 

Please be aware that tuning a system requires that the bootable kernel be changed–not something to be done by a novice! Also, the system will need to be rebooted to test the new kernel, so you will experience some system down time. We don’t suggest testing the new kernel on the day that payroll is run, unless you want all your users watching you very closely, especially since tuning also has an element of trial and error. You will find it’s often a balancing act between disk buffers and user memory, and may take a few tries to hit the correct balance for your system (or you may find that your system needs more RAM). Once you tune the system, you will still need to monitor its performance. Then, if your system changes with more terminals, more memory, new applications–guess what–it’s time to retune! 

Your initial system configuration, out of the box, is based on an average user environment, whatever that is. It’s not too surprising that most systems need to be fine tuned. To help you determine how best to tune your kernel, you need to review your system’s performance over a period of time. Make sure that you are reviewing your system at appropriate times, not lunch or weekends. Some operating systems have “system activity reports” that will capture this information for you. Also, there are both public and commercial programs (for some strange reason, almost all of them are called “monitor”) that can help you. You can also use “ps” to take periodic “snapshots” of your system to determine trends and processes running on the system. When reviewing your system’s performance, be sure that you evaluate what processes are being run (are there any “runaway” processes?), who is running them, and are any processes taking a long time to execute. These answers can guide you in defining your system’s usage patterns and help you determine if changes should be made. 

Once you determine your normal memory usage, subtract that number from the amount of memory on your system. (How you determine what is normal, is an interesting question by itself. We leave that one as an exercise for the student!) The remaining memory can, and should be, allocated to buffering by increasing your NBUFS (system buffers) and HBUFS (hash buffers). The quantity of memory allocated to each represents a tradeoff between disk buffers and user memory. Optimum performance is usually achieved when there is enough memory to hold all of the processes that normally run simultaneously, and the remaining memory is occupied by various buffers (“bufs”). Having too many disk buffers will likely decrease performance by reducing the memory available to user programs, which will cause more swapping. In addition, the maximum user process size will decrease. Having too few buffers causes additional time to be spent performing disk I/O. It will probably be necessary to try several values of “bufs” to fine tune the needs of a particular system, depending on the applications in use, and the amount of available memory. If there is no happy medium to be found, you may need more RAM. 

Allocating inodes, files, and locking has an easy rule of thumb. Count one for each file opened, then 25% more just in case. For example, on a system of 16 terminals, each using 20 files, that would mean about 380 X 1.25, or about 450 files, inodes, and locks. These shouldn’t overflow, but allocating too many wastes memory. 

One of the best books, in our opinion, which discusses the tunable elements available is The Design of the Unix Operating System; Maurice J. Back, Prentice-Hall. It does not give specific tuning instructions, but rather describes the various parameters and their general effects. You may also find the original AT&T articles on Unix helpful. For additional and more specific information, see your operating system manuals. 

For improved system performance, there are several other elements to consider in addition to tuning the kernel. Directory sizes, file distribution, disk fragmentation, and system use can also be significant factors in performance. Xenix/Unix is not adept in accessing large directories. If you have large directories, say above 250 files, try to move some of the files to another directory or file system. If you have more than one disk drive, distribute the files across the drives so that one is not overly taxed. Disk fragmentation also contributes to reduced performance because the heads must move great distances to access data that should be contiguous. Fragmentation is partly due to the nature of Xenix/Unix, as free blocks are not always listed in physical order. This can make I/O become less efficient. Fragmentation can be corrected by rearranging the free block list or copying a file system to another partition on the disk or to a tape, removing the original file system, and then copy it back. This process is time consuming, but will generally improve performance because the disk access time will be improved. 

System performance can also be improved by making sure that the system is being effectively used. Less important jobs should not interfere with more important jobs. Determine which jobs can be run when the system is not so busy, and perhaps set up ‘crons’ to run the jobs during off-hours. Also, make sure that $PATH is efficiently set up. It is read left to right, so the most likely places to find the command should be first in the path. Make sure that a directory is not being searched more than once. Additionally, if you have terminal ports with no terminals attached, make sure there is no getty running for that port. 

Improving system performance is one of those never-ending quests of the programmer. As you can see, the variables are endless, and each and every one of them has a bearing on the problem. In lieu of absolute answers (which don’t exist), these ideas should help guide you through the process. Happy tuning! 

Last Modified: 05/03/1999 Product: PRO/5 Operating System: UNIX Error Number: 2, 15

BASIS structures five components of their technology into the BBx Generations.