OSI/TS Configuration and Management Manual

Performing Monitoring and Troubleshooting Guide
OSI/TS Configuration and Management Manual—424831-001
4-5
When to Monitor Performance
When to Monitor Performance
Tuning your system to improve performance is an iterative process that begins with
initial configuration. As you monitor the system and uncover problem areas, you adjust
and reconfigure to improve performance.
To obtain appropriate performance data, you need to carefully select the times when
monitoring activities are performed. If possible, measure the system for a full day.
Repeat the measurements for peak days for the applications, if known, such as special
days of the month, special days or months of the year, and so on. Monitor the subsystem
during the busiest hours of the days that are most critical for system operation.
Improving Performance
Once you have obtained performance data via monitoring, you may need to take
corrective action. The actions required to correct performance problems, of course,
depend on the symptoms and the types of problems encountered. Don’t automatically
add more memory or other hardware. In some instances, adding more hardware can
intensify the problem, or can create other problems. To do the job properly, you should
first analyze what is happening in the system, determine the causes, and then attempt to
treat the problems—not the symptoms. For additional information on performance, see
Section 3, Configuring the OSI/TS Subsystem
.
The various performance indicators that you can monitor describe different aspects of
the behavior of a subsystem. However, these indicators are generally not independent of
each other; they are interrelated. Changing one factor or attribute, or making haphazard
changes to attributes, doesn't always improve the functioning of your system. The net
effect may be to make the situation worse.
Goals
The overall goal is to avoid the overutilization of your subsystem resources. General
guidelines suggest spreading the workload evenly across all the hardware and software
resources that make up the subsystem. To reduce the overhead, you can add
communications lines, disks, CPUs, and other hardware. To restrict throughput (and
thereby improve response time), you can control the number of processes on the
subsystem and you can make the application programs more efficient. If queuing delays
on a communications line are excessive, determine the cause (line or CPU) and work to
reduce contention. If you cant add more hardware, you can reduce the less-important
activities during peak periods.
Testing Changes
Any proposed changes should be tested, if possible, before being introduced into the
production system. If you cant test them, you should carefully consider the implications
of the changes and monitor the subsystem closely after the changes are implemented.
Each change you make to the system can affect a number of different system resources.
Therefore, it is very important to make only one change at a time. If performance is still
a problem, note the change you made and continue with your analysis.