|
|
 |
|
| |
NOTE: CentOS Enterprise Linux is built from the Red Hat Enterprise Linux source code. Other than logo and name changes CentOS Enterprise Linux is compatible with the equivalent Red Hat version. This document applies equally to both Red Hat and CentOS Enterprise Linux.
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.
Here are the two main facts about processing power that you
should keep in mind:
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, much less increase
it.
Processing power is also fixed in another way: it is finite.
That is, there are limits to the types of CPUs that can be plugged
into any given computer. Some systems are capable of supporting a
wide range of CPUs of differing speeds, while others may not be
upgradeable at all.
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 worth of
processing that have been wasted.
If we take these facts and examine 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.
The next section defines these consumers.
There are two main consumers of processing power:
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, applications are the reason you
have a computer.
A single-CPU system can only do 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 seemingly run
at once under a modern operating system? The answer is that these
are multitasking operating systems. In other words, they create the
illusion that many different things are going on simultaneously
when in fact that is not possible. 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 the next fraction of a
second. If these context switches happen
frequently 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 devices such as disk drives and graphics displays. When
these events take place, the application no longer needs the CPU.
At these times, the CPU can be used for other processes running
other applications without slowing the waiting application at
all.
In addition, the CPU can be used by another consumer of
processing power: the operating system itself.
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, for example, it is easy to use a
process monitor to determine what the process running a daemon or service is
doing, it is not so easy to determine how much processing power is
being consumed by system-level I/O-related processing (which is
normally done within the context of the process requesting the
I/O.)
In general, it is possible to divide this kind of operating
system overhead into two types:
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, such as processes handling system-wide event logging or I/O
cache flushing.
When there is insufficient processing power available for the
work needing to be done, you have two options:
-
Reducing the load
-
Increasing the capacity
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 under your control that can be cut back. There are
three areas to focus on:
-
Reducing operating system overhead
-
Reducing application overhead
-
Eliminating applications entirely
To reduce operating system overhead, you must examine your
current system load and determine what aspects of it result in
inordinate amounts of overhead. These areas could include:
Do not expect miracles; in a reasonably-well configured system,
it is unlikely to notice much of a performance increase by trying
to reduce operating system overhead. This is due to the fact that a
reasonably-well configured system, by definition, results 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 means making sure 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, for example.
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.
Depending on your organization, this approach might not be
available to you, as it often is not a system administrator's
responsibility to dictate which applications will and will not be
run. However, if you can identify any applications that are known
"CPU hogs", you might be able to influence the powers-that-be 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.
|
Of course, if it is not possible to reduce the demand for
processing power, you must find ways of increasing the processing
power that is available. To do so costs money, but it can be
done.
The most straightforward approach is to determine if your
system's CPU can be upgraded. The first step is to determine 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 possible —
at least in theory.
Next, you must 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?
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. If it does not, a motherboard upgrade (at the
least) would be required.
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 requires 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
does 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 does not help
workloads consisting 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 without 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. It provides the most CPU power
with the fewest restrictions on its use.
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 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 can impact the system-wide load less on a multi-processor
machine.
|
|
|
