Cover V02, I03
tr>
Article
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Sidebar 1
Sidebar 2

may93.tar


Sidebar: CPU Utilization and X

Where in the past, UNIX users typically worked on standard async terminals or CRTs that ran and processed I/O for only one application at a time, today's X Windows/Motif users can run several applications, X Windows and non-X Windows, at one time, on one terminal. Multiple applications execute within several windows on a large graphical terminal provided through X Windows and Motif. These terminals replace the older drab character-based display with a new graphical user interface that users love.

The increase in the process load generated by X systems brings CPU utilization up to a maximum. Figure 6, for example, shows a process status listing (ps -eaf) of the programs operating on only one computer running only one X Server. Notice the number of X and Motif management daemons running, as well as several X applications and such normal UNIX processes as cron and lpsched. This load is relatively light compared to that generated by X systems processing database operations or data acquisition tasks, which are pet applications for X Windows system developers.

This increased work load puts system administrators in a dilemma, given that a single X Terminal can absorb more CPU cycles than ten or more older character-based terminals. Along with the configuration and performance monitoring measures discussed in the article (and apart from expensive ideas like new processors), there are a number of little things can you do to increase the speed of X Windows.

First, your system may be able to do without certain processes, including: accounting system daemons, mail system daemons, network daemons, printer control daemons, and security daemons. Security daemons (such as the ones that come with "Secure UNIX") are significant CPU and I/O users; they can usually be disabled or even removed, though not if you're working for the CIA or another organization where security is a high priority.

Second, you can train users to run large, CPU-intensive tasks (such as DBMS operations) at night when the CPU has more idle time, or get them to run the tasks at a lower priority. While users are more difficult to manage than the system itself, you can show them how to use some of UNIX's delay execution and prioritization facilities.

Sharing the Load

Another stratagem is to use the X Window system's ability to distribute the processing load over several CPUs. This allows the most burdened system to move processes to other CPUs connected via a network (loosely coupled processors). Using the "remote control" facilities provided by UNIX, such as rsh, rlogin, or telnet, users can change the execution location of X or Motif applications.

The key is to determine which programs should run where. With a little trial and error, you can balance the process load among the connected CPUs and then train users to show them how X applications can be executed on remote CPUs. Executed properly, load sharing can be a major benefit to overall system and X performance. It can also be an administrator's nightmare if activity on all processors is not constantly monitored.