Processing Power
Often known as CPU power, CPU cycles, and various other names, processing power is the ability of a computer to manipulate data. Processing power varies with the architecture (and clock speed) of the CPU — usually CPUs with higher clock speeds and those supporting larger word sizes have more processing power than slower CPUs supporting smaller word sizes.
Facts About Processing Power
There are two main facts about processing power that you should keep in mind:
It is fixed
It cannot be stored
Processing power is fixed, in that the CPU can only go so fast. For example, if you need to add two numbers together (an operation that takes only one machine instruction on most architectures), a particular CPU can do it at one speed, and one speed only. With few exceptions, it is not even possible to slow the rate at which a CPU processes instructions.
Processing power is also fixed in another way: it is finite. That is, there are limits to the CPU performance you can put into any given computer. Some systems are capable of supporting a wide range of CPU speeds, while others may not be upgradeable at all[1].
Processing power cannot be stored for later use. In other words, if a CPU can process 100 million instructions in one second, one second of idle time equals 100 million instructions that have been wasted.
If we take these facts and look at them from a slightly different perspective, a CPU "produces" a stream of executed instructions at a fixed rate. And if the CPU produces executed instructions, that means that something else must "consume" them.
Consumers of Processing Power
There are two main consumers of processing power:
Applications
The operating system itself
Applications
The most obvious consumers of processing power are the applications and programs you want the computer to run for you. From a spreadsheet to a database, these are the reasons you have a computer.
A single-CPU system can only run one thing at any given time. Therefore, if your application is running, everything else on the system is not. And the opposite is, of course, true — if something other than your application is running, then your application is doing nothing.
But how is it that many different applications can run at once under Red Hat Linux? The answer is that Red Hat Linux is a multitasking operating system. In other words, it creates the illusion that many things are going on simultaneously when in fact that is impossible. The trick is to give each process a fraction of a second's worth of time running on the CPU before giving the CPU to another process for another fraction of a second. If these context switches happen quickly enough, the illusion of multiple applications running simultaneously is achieved.
Of course, applications do other things than manipulate data using the CPU. They may wait for user input as well as performing I/O to many devices, including disk drives and graphics displays. When these events take place, the application does not need the CPU. At these times, the CPU can be used for other processes running other applications.
In addition, the CPU can be used by another consumer of processing power: the operating system itself.
The Operating System
It is difficult to determine how much processing power is consumed by the operating system. The reason for this is that operating systems use a mixture of process-level and system-level code to perform their work. While it is easy to use top to see what the process running syslogd is doing (for example), it is not so easy to see how much processing power is being consumed by I/O-related processing.
In general, it is possible to divide this kind of operating system overhead into two types:
Operating system housekeeping
Process-related activities
Operating system housekeeping includes activities such as process scheduling and memory management, while process-related activities include any processes that support the operating system itself (including system daemons such as syslogd, klogd, etc.).
Improving a CPU Shortage
When there is insufficient processing power available for the work that needs to be done, you have two options:
Reducing the load
Increasing Capacity
Reducing the Load
Reducing the CPU load is something that can be done with no expenditure of money. The trick is to identify those aspects of the system load that are under your control and can be cut back. There are three areas to focus on:
Reducing operating system overhead
Reducing application overhead
Eliminating applications entirely
Reducing Operating System Overhead
In order to reduce operating system overhead, you will have to look at your current system load, and determine what aspects of it result in inordinate amounts of overhead. These areas could include:
Reducing the need for frequent process scheduling
Lowering the amount of I/O performed
Do not expect miracles; in a reasonably-well configured system, it is unlikely that you will see much of a performance increase by trying to reduce operating system overhead. This is due to the fact that a reasonably-well configured system will, by definition, result in a minimal amount of overhead. However, if your system is running with too little RAM for instance, you may be able to reduce overhead by alleviating the RAM shortage.
Reducing Application Overhead
Reducing application overhead simply means making sure that the application has everything it needs to run well. Some applications exhibit wildly different behaviors under different environments — an application may become highly compute-bound while processing certain types of data, but not others.
The point to keep in mind here is that you must understand the applications running on your system if you are to enable them to run as efficiently as possible. Often this entails working with your users, and/or your organization's developers, to help uncover ways in which the applications can be made to run more efficiently.
Eliminating Applications Entirely
Depending on your organization, this approach might not be available to you, as it often is not a system administrator's job to dictate which application will and will not be run. However, if you can identify any applications that are known "CPU hogs", you might be able to retire them.
Doing this will likely involve more than just yourself. The affected users should certainly be a part of this process; in many cases they may have the knowledge and the political power to make the necessary changes to the application lineup.
 | Tip |
|---|---|
Keep in mind that an application may not need to be eliminated from every system in your organization. You might be able to move a particularly CPU-hungry application from an overloaded system to another system that is nearly idle. |
Increasing Capacity
Of course, if it is not possible to reduce the demand for processing power, you will have to find ways of increasing the processing power that is available. To do so will cost money, but it can be done.
Upgrading the CPU
The most straightforward approach is to determine if your system's CPU can be upgraded. The first step is to see if the current CPU can be removed. Some systems (primarily laptops) have CPUs that are soldered in place, making an upgrade impossible. The rest, however, have socketed CPUs, making upgrades theoretically possible.
Next, you will have to do some research to determine if a faster CPU exists for your system configuration. For example, if you currently have a 1GHz CPU, and a 2GHz unit of the same type exists, an upgrade might be possible.
Finally, you must determine the maximum clock speed supported by your system. To continue the example above, even if a 2GHz CPU of the proper type exists, a simple CPU swap is not an option if your system only supports processors running at 1GHz or below.
Should you find that you cannot install a faster CPU in your system, your options may be limited to changing motherboards, or even the more expensive forklift upgrade mentioned earlier.
However, some system configurations make a slightly different approach possible. Instead of replacing the current CPU, why not just add another one?
Is Symmetric Multiprocessing Right for You?
Symmetric multiprocessing (also known as SMP) makes it possible for a computer system to have more than one CPU sharing all system resources. This means that, unlike a uniprocessor system, an SMP system may actually have more than one process running at the same time.
At first glance, this seems like any system administrator's dream. First and foremost, SMP makes it possible to increase a system's CPU power even if CPUs with faster clock speeds are not available — just by adding another CPU. However, this flexibility comes with some caveats.
The first caveat is that not all systems are capable of SMP operation. Your system must have a motherboard designed to support multiple processors.
The second caveat is that SMP increases system overhead. This makes sense if you stop to think about it; with more CPUs to schedule work for, the operating system will require more CPU cycles for overhead. Another aspect to this is that with multiple CPUs, there can be more contention for system resources. Because of these factors, upgrading a dual-processor system to a quad-processor unit will not result in a 100% increase in available CPU power. In fact, depending on the actual hardware, the workload, and the processor architecture, it is possible to reach a point where the addition of another processor could actually reduce system performance.
Another point to keep in mind is that SMP will not help workloads that consist of one monolithic application with a single stream of execution. In other words, if a large compute-bound simulation program runs as one process and with no threads, it will not run any faster on an SMP system than on a single-processor machine. In fact, it may even run somewhat slower, due to the increased overhead SMP brings. For these reasons, many system administrators feel that when it comes to CPU power, single stream processing power is the way to go.
While this discussion seems to indicate that SMP is never a good idea, there are circumstances in which it makes sense. For example, environments running multiple highly compute-bound applications are good candidates for SMP. The reason for this is that applications that do nothing but compute for long periods of time keep contention between active processes (and therefore, the operating system overhead) to a minimum, while the processes themselves will keep every CPU busy.
One other thing to keep in mind about SMP is that the performance of an SMP system tends to degrade more gracefully as the system load increases. This does make SMP systems popular in server and multi-user environments, as the ever-changing process mix will impact the system-wide load less on a multi-processor machine.