Java Reference
In-Depth Information
able) atomic operations on integers or object references, and are implemented using low-level
concurrency primitives (such as compare-and-swap) provided by most modern processors.
If your class has a small number of hot fields that do not participate in invariants with oth-
er variables, replacing them with atomic variables may improve scalability. (Changing your
algorithm to have fewer hot fields might improve scalability even more—atomic variables
reduce the cost of updating hot fields, but they don't eliminate it.)
11.4.6. Monitoring CPU Utilization
When testing for scalability, the goal is usually to keep the processors fully utilized. Tools
like
vmstat
and
mpstat
on Unix systems or
perfmon
on Windows systems can tell you
just how “hot” the processors are running.
If the CPUs are asymmetrically utilized (some CPUs are running hot but others are not) your
first goal should be to find increased parallelism in your program. Asymmetric utilization in-
dicates that most of the computation is going on in a small set of threads, and your application
will not be able to take advantage of additional processors.
If the CPUs are not fully utilized, you need to figure out why. There are several likely causes:
Insufficent load.
It may be that the application being tested is just not subjected to enough
load. You can test for this by increasing the load and measuring changes in utilization,
response time, or service time. Generating enough load to saturate an application can
require substantial computer power; the problem may be that the client systems, not
the system being tested, are running at capacity.
I/O-bound.
You can determine whether an application is disk-bound using
iostat
or
perfmon
, and whether it is bandwidth-limited by monitoring traffic levels on your
network.
Externally bound.
If your application depends on external services such as a database or
web service, the bottleneck may not be in your code. You can test for this by using a
profiler or database administration tools to determine how much time is being spent
waiting for answers from the external service.
Lock contention.
Profiling tools can tell you how much lock contention your application
is experiencing and which locks are “hot”. You can often get the same information
without a profiler through random sampling, triggering a few thread dumps and look-
ing for threads contending for locks. If a thread is blocked waiting for a lock, the
appropriate stack frame in the thread dump indicates “waiting to lock monitor . . . ”
Locks that are mostly uncontended rarely show up in a thread dump; a heavily con-
