Tuning for X

David S. Linthicum

Introduction

Want to use X Windows? Be warned that if not configured and managed correctly, X can be an out-of-control resource hog capable of bringing even a muscle-bound processor to its knees. To prevent this, you need first to understand the basics of the X Window system and how it uses such UNIX subsystems as memory and the CPU (see the accompanying sidebars for information on memory and CPU utilization). Then, with the basics in mind, you can go on to configuration and tuning issues.

This article covers some of the more important of those issues -- including drivers, memory utilization, and the UNIX tunables that can be adjusted to squeeze the most performance out of your system. The article also discusses how to measure X Window performance using available benchmarking and system monitoring facilities, and how to use these facilities to spot and solve problems. The examples I use here come from a SunSoft Interactive 386/ix 3.0 (System V) workstation running X11 and Motif. Other systems, especially those running non-System V UNIX, may yield different results.

Configuring Resources

Most X applications use resources to customize the way the X Terminal and X applications look and function. This allows system administrators to control the number of processes executed by default and the amount of memory and processor time being used. For example, since it takes more memory to load a full-color background than a plain background, you can protect limited memory resources by allowing only a plain background to load.

The X system stores resource information in a series of text files called resource files. These files provide for system-wide, account-wide, and class-wide resource settings, allowing the system administrator to configure a hierarchy of resource defaults to control the use of memory and CPU by level. When an X application is invoked, the X system checks the X-server-wide "Resource Manager" for the stored resource commands. The application itself must check other configuration files located throughout the file system.

Resource settings can be Boolean or can take numeric values. Default values are set in resource files in the user's home directory and in the X resource database manager, xrdb. This utility stores resources directly in the server, thus making them available to all X clients.

Even individual X applications store default resource files within the file system, usually /usr/lib/X11/app- defaults. Such files configure the actions and the presentation of a single program. Figure 1 , for example, contains the default settings for the X application xload.

The primary resource files (.Xdefaults or .Xresources), stored in the home directory of the users, determine the defaults for the client applications. These defaults can be set system-wide by the system administrator (see Figure 2). Custom resources can even be set by the CPU if a network is employed. Command-line options take precedence over defaults set in the resource files and users can override the defaults for whatever reason, if needed.

Reconfiguring and Rebuilding the UNIX Kernel

The kernel is the "traffic cop" of the UNIX operating system. It controls the memory, schedules processes, and manages I/O and every other task associated with an operating system. The kernel is always present in physical memory (never paged) and can be quite large, especially on systems where it is clogged with several device drivers.

Your primary goal regarding overall X system performance should be to minimize the memory requirement of the kernel. You can accomplish this by setting parameters in the kernel's configuration files (see the stune file in Figure 3) and relinking or building a new kernel, which takes effect upon the next boot.

The process of configuring the kernel varies from one version to the other, but most versions provide interactive programs that will configure the kernel for you. On SCO ODT systems this is the tunesh utility, new with version 2.0. On SunSoft 386/ix systems, administrators can use the kconfig utility. Other UNIX systems may have their own version of this facility. It's generally safer to go through these kernel configuration utilities rather than edit the tunable files directly. If you do edit the file(s) directly, be sure to make backups so that you can restore the system if you get yourself into too much trouble.

Tunable Parameters

This section examines some of the more important tunable parameters and discusses their significance for tuning X.

NBUF controls the number of buffer headers allocated at one time. When this number is reduced, the system is forced to allocate buffers more often, which can have a negative effect on system performance. When NBUF is increased, the system can allocate buffers less often, but the additional buffers take up valuable memory. You can find the optimal NBUF setting by monitoring system performance.

NPROC sets the size of the process table -- that is, the maximum number of simultaneous processes that the system can run at one time. This parameter is particularly significant for X systems, because a typical X Workstation runs many processes simultaneously. If NPROC is set too low, users may receive a "cannot fork: too many processes" message when the specified number of processes is exceeded.

NREGION sets the number of program regions that are allowed to be active at any given time. There are three regions in a UNIX process: text, data, and the program stack. As a rule of thumb, this parameter should be set to at least three times the size of NPROC.

MAXUP sets the maximum number of processes that a single user can have active at one time. This must always be less than the number set for NPROC, but should be set relatively high for X, since an X workstation typically runs many processes. Generally speaking, users should be able to run at least 90 percent of the NPROC number. If the number of processes is exceeded, the user receives a "too many processes" message.

NHBUF sets the number of "hash buckets" to allocate for the buffer cache system. Increasing this value makes the cache searches more efficient. As a rule, it is usually 1/4 of the number set by the NBUF parameter and must be a power of 2.

NAUTOUP sets the number of seconds between buffer flushes to disk. If it is too high, the system reliability may be sacrificed but X performance is increased (slightly). If this parameter is set too low, system performance is affected negatively.

NSTREAM sets the maximum number of streams that can be opened at any given time and is very important to X. Because the X Window system uses the STREAMS package, the more X activity on your CPU, the higher this parameter should be set. Generally speaking, systems running X should set this value over 100.

NQUEUE is another STREAMS tunable parameter. This value should be set at four times the value set in NSTREAM.

NBLKn specifies the number of data blocks and data buffers of size n. The STREAMS facility of UNIX uses these parameters to allocate message blocks and buffers within the system. The nimber of message blocks of size n is about 1.25 times the number of data blocks of size n. As with the other parameters that affect STREAMS, these are very important to the performance of the X Window system.

CPU Tuning Considerations

If you support a great many X Terminals, you should consider increasing the size of the process table (NPROC and MAXUP for System V; maxusers and MAXUPRC for BSD). This is particularly important if there are several users operating X Windows at the same time via X Terminals and other remote display devices.

Two idiosyncrasies make X Windows a problem. The first is that it requires processes of its very own. The second is that users tend to open lots of windows and run lots of X and Motif applications. Each window requires at least two processes -- in some cases, more than two. These processes consist of a terminal emulator, a shell, and the actual X/Motif application.

The obvious answer -- to increase the size of the process table -- brings problems of its own. If the process table is too large, it will require too much memory and force the system to begin swapping. Swapping slows X Windows (and everything else) to a crawl. If the process table is too small, not enough space is allocated to handle the extensive process load of systems running X Windows (see the sidebar "CPU Utilization and X" for more information).

Benchmarking X

Benchmarking allows you to determine whether your new configuration has hurt or helped overall system and X Windows performance. The measure in a benchmark test is the length of time taken to execute a set of X Window operations.

UNIX provides several tools you can use to perform a benchmark, and other benchmarking programs are available from various sources. Some of these are specifically designed for X; others, for UNIX as a whole. The following are benchmarking tools that you may find helpful.

x11perf -- This X Terminal benchmark can measure 276 different types of X requests. It requires X Windows. I have found it to be the best available for measuring X performance. The x11perf system is available on UUNET.

xbench -- This X Windows-oriented benchmarking utility measures some commonly used X functions and started the ratings know as Xstones. The xbench system requires X Windows. A shortcoming of the xbench system is that is does not take into account different screen sizes or resolutions. Also, if fonts are in use, it does not factor them into the benchmark. These omissions mean that an xbench test may not truly represent the actual performance of the X Terminal. However, xbench may be a good tool for comparing two or more X Terminals. Figure 4 shows a sample xbench results file. The xbench system is available on UUNET.

xload -- xload provides the user with a graphic display of certain system performance statistics. The xload program requires X Windows. Although nice to look at and neat to use, xload does not provide enough information to make it a very useful X benchmarking tool. This program comes with most X systems.

sar -- Because of its versatility, sar is one of the most popular benchmarking utilities. sar provides information pertaining to CPU and memory usage, including idle time. This utility is available only on System V UNIX. Figure 5 presents a few sar reports. Notice the last listing: this sar report was run while X Windows was running on a 386 with just 3 megabytes -- it shows a very slow, sick system screaming for additional memory.

sar can also be used to produce system performance reports. The following are reports available with sar; most of these are helpful when testing a system running X: