IBM Power7 Optimization And Tuning Manual page 34

– The network utilization of the application: Networks can be a bottleneck in execution
either because of bandwidth or latency issues. Link aggregation techniques are often
used to solve networking issues.
– The disk utilization of the application: High disk I/O issues are increasingly being
solved by using solid-state disks (SSDs).
Common operating system tools for gathering this general information include topas (AIX),
top (Linux), vmstat, and netstat. Detailed CPU usage information is available by running
sar. This command diagnoses cases where some logical processors are saturated and
others are underutilized, an issue that is seen with network interrupt processing on Linux.
2. Collect a time-based profile of the application to see where execution time is concentrated.
Some possible areas of concern are:
– Particular user routines or Java methods with a high concentration of execution time.
This situation is an indication of a poor coding practice or an inefficient algorithm that is
being used in the application itself.
– Particular library routines or Java class library methods with a high concentration of
execution time. First, determine whether the hot routine or method is legitimately used
to that extent. Look for alternatives or more efficient versions, such as using the
optimized libraries in the Linux Advance Toolchain or the vector routines in the MASS
library (for more information, see "Mathematical Acceleration Subsystem Library and
Engineering and Scientific Subroutine Library" on page 11).
– A concentration of execution time in the pthreads library (see "Java profiling example"
on page 178) or in kernel locking (see "AIX kernel locking services" on page 38)
routines. This situation is associated with a locking issue. This locking might ultimately
arise at the system level (as seen with malloc locking issues on AIX), or at the
application level in Java code (associated with synchronized blocks or methods in Java
code). The source of locking issues is not always immediately apparent from a profile.
For example, with AIX malloc locking issues, the time that is spent in the malloc and
free routines might be quite low, with almost all of the impact appearing in kernel
locking routines.
The tools for gathering profiles are tprof (AIX) and Oprofile (Linux) (both tools are
described in "Rational Performance Advisor" on page 161). The curt tool (see "AIX
trace-based analysis tools" on page 165) also provides a breakdown, describing where
CPU time is consumed and includes more useful information, such as a system
call summary.
3. Where there are indications of a locking issue, collect locking information.
With locking problems, the primary concern is to determine where the locking originates in
the application source code. Cases such as AIX malloc locking can be easily solved just
by switching to a more scalable memory allocation package through the MALLOCTYPE and
MALLOCOPTIONS environment variables. In this case, you should examine how malloc is
used and consider making changes at the source code level. For example, rather than
repeatedly allocating many small blocks of memory by calling malloc for each block, the
application can allocate an array of blocks and then internally manage
the space.
As mentioned in "java/util/concurrent" on page 12, Java locking issues that are associated
with some older classes, such as java/util/Hashtable, can be easily solved by using
java/util/concurrent/ConcurrentHashMap.
For Java programs, use
non Java programs, use the splat tool on AIX (see "AIX trace-based analysis tools" on
page 165).
18
POWER7 and POWER7+ Optimization and Tuning Guide
Java Lock Monitor (see "Java Health Center" on page 177). For