Tuning for X
David S. Linthicum
Want to use X Windows? Be warned that if not configured
correctly, X can be an out-of-control resource hog capable
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
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
including drivers, memory utilization, and the UNIX
can be adjusted to squeeze the most performance out
of your system.
The article also discusses how to measure X Window performance
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
running X11 and Motif. Other systems, especially those
V UNIX, may yield different results.
Most X applications use resources to customize the way
the X Terminal
and X applications look and function. This allows system
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
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,
and class-wide resource settings, allowing the system
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
files located throughout the file system.
Resource settings can be Boolean or can take numeric
values are set in resource files in the user's home
in the X resource database manager, xrdb. This utility
resources directly in the server, thus making them available
Even individual X applications store default resource
the file system, usually /usr/lib/X11/app- defaults.
configure the actions and the presentation of a single
program. Figure 1
, for example, contains the default settings for the
The primary resource files (.Xdefaults or .Xresources),
stored in the home directory of the users, determine
for the client applications. These defaults can be set
by the system administrator (see Figure 2). Custom resources
be set by the CPU if a network is employed. Command-line
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
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
to minimize the memory requirement of the kernel. You
this by setting parameters in the kernel's configuration
the stune file in Figure 3) and relinking or building
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
new with version 2.0. On SunSoft 386/ix systems, administrators
use the kconfig utility. Other UNIX systems may have
own version of this facility. It's generally safer to
go through these
kernel configuration utilities rather than edit the
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
This section examines some of the more important tunable
and discusses their significance for tuning X.
NBUF controls the number of buffer headers allocated
time. When this number is reduced, the system is forced
buffers more often, which can have a negative effect
on system performance.
When NBUF is increased, the system can allocate buffers
often, but the additional buffers take up valuable memory.
find the optimal NBUF setting by monitoring system performance.
NPROC sets the size of the process table -- that is,
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
If NPROC is set too low, users may receive a "cannot
too many processes" message when the specified
number of processes
NREGION sets the number of program regions that are
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
can have active at one time. This must always be less
than the number
set for NPROC, but should be set relatively high for
an X workstation typically runs many processes. Generally
users should be able to run at least 90 percent of the
number. If the number of processes is exceeded, the
a "too many processes" message.
NHBUF sets the number of "hash buckets" to
for the buffer cache system. Increasing this value makes
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
disk. If it is too high, the system reliability may
but X performance is increased (slightly). If this parameter
too low, system performance is affected negatively.
NSTREAM sets the maximum number of streams that can
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,
running X should set this value over 100.
NQUEUE is another STREAMS tunable parameter. This value
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.
of message blocks of size n is about 1.25 times the
of data blocks of size n. As with the other parameters
affect STREAMS, these are very important to the performance
X Window system.
CPU Tuning Considerations
If you support a great many X Terminals, you should
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
to open lots of windows and run lots of X and Motif
Each window requires at least two processes -- in some
than two. These processes consist of a terminal emulator,
and the actual X/Motif application.
The obvious answer -- to increase the size of the process
-- 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
the extensive process load of systems running X Windows
(see the sidebar
"CPU Utilization and X" for more information).
Benchmarking allows you to determine whether your new
has hurt or helped overall system and X Windows performance.
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
other benchmarking programs are available from various
of these are specifically designed for X; others, for
UNIX as a whole.
The following are benchmarking tools that you may find
x11perf -- This X Terminal benchmark can measure 276
types of X requests. It requires X Windows. I have found
it to be
the best available for measuring X performance. The
system is available on UUNET.
xbench -- This X Windows-oriented benchmarking utility
some commonly used X functions and started the ratings
know as Xstones.
The xbench system requires X Windows. A shortcoming
xbench system is that is does not take into account
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
X Terminals. Figure 4 shows a sample xbench results
xbench system is available on UUNET.
xload -- xload provides the user with a graphic display
of certain system performance statistics. The xload
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
pertaining to CPU and memory usage, including idle time.
is available only on System V UNIX. Figure 5 presents
a few sar
reports. Notice the last listing: this sar report was
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
are helpful when testing a system running X:
Buffer cache usage and hit rate
Kernel memory allocation activity
Average queue length
Unused memory pages and disk blocks
Status of system tables
Swapping and paging activity
The Network Subsystem
X is often used over an Ethernet network that connects
the X Server
(such as an X Terminal or X Workstation) to the client.
speaking, the Ethernet network provides a large enough
performance of an X Terminal will not be hindered. Problems
occur can usually be easily diagnosed with the standard
facilities. The network should not be the primary focus
the system for maximum X performance, but there are
a few things to
First, the network must be capable of transferring data
Second, the network must have sufficient bandwidth to
traffic on the network. If the bandwidth is too short,
information takes too long to move from client to server
again. Each system must have the capacity to handle
the network processing
load assigned to that particular node. One slow system
can cause the
entire network's performance to suffer, thus hindering
of X Windows.
Device Driver Considerations
The most important I/O device for X Windows is the graphics
-- or graphics adapter if a workstation is employed
-- and graphics
device drivers are critical to UNIX system tuning. Poorly
or improperly configured drivers can significantly diminish
application response time. Writing device drivers to
is most likely the UNIX or device vendor's job and is
thus out of
your control. But a super-fast graphics controller or
adapter is useless
if the driver in use is not optimized correctly. It
may bring the
performance of the X Terminal down to a crawl.
You can make your UNIX system a better X Windows workhorse
tuning tools (such as the benchmarking facilities described
and by gaining a knowledge of UNIX subsystems that affect
You'll find that in the world of X things are going
to get much worse
in terms of processor and memory loads required. This
will be your
challenge for the 90s.
Hare, Chris. "Getting the Info -- u386mon."
Sys Admin. September/October 1992.
Johnson, Eric F, and Kevin Reichard. Using X,
Troubleshooting the X Window System, Motif & Open
Laukides, Mike. System Performance Tuning.
Sebastopol, CA: O'Reilly & Associates, 1990.
Linthicum, David S. "UNIX Facilities for Database
Tuning." Database Programming and Design. January
Quercia, Valerie & Tim O'Reilly. X Window System
User's Guide. Sebastopol, CA: O'Reilly & Associates,
Taht, Michael. "Configuring for X Terminals."
SCO Magazine. October 1992.
About the Author
David Linthicum is currently working with Mobil Oil
Virginia, as a Senior Software Engineer. The author
of over a dozen
articles appearing in several technical publications,
he just completed
a book for Microtrend entitled: Motif Programmer's Library,
in the beginning of 1993. He is also the co-author of
a book entitled:
Introduction to Programming for Que, which was released
of 1992. Dave teaches System Analysis and Design and
at Northern Virginia Community College in Sterling,
has been teaching there since 1987. He can be reached
at (703) 818-9164
or at firstname.lastname@example.org.