IBM 170 Servers Manual page 31

2. A similar effect can be found with index builds. If parallelism is enabled, index creation (CRTLF,
Create Index, Open a file with MAINT(*REBUILD), or running a query that requires an index to
be build) will be sent to service jobs that operate in non-interactive mode, but charge their work
back to the job that requested the service. Again, the work does not count as "interactive", but the
performance data will show the resource consumption as if they were.
Lastly when only a single interactive job is running, the machine grants an exemption and does not
include this job's activity in the interactive feature utilization.
There are two key ideas in the statements above. First, if the workload has a significant component that is
related to queries or there is a single interactive job running, it will be possible to show an interactive job
utilization in the performance tools that is significantly higher than what would be assumed and reported
from the ratings of the Interactive Feature and the Processor Feature. Second, although it may make
monitoring interactive utilization slightly more difficult, in the case where the workload has a significant
query component, it may be beneficial to set the QQRYDEGREE system value to allow at least 2
processes, so that index builds and many queries can be run in non-interactive mode. Of course, if the
nature of the query is such that it cannot be split into multiple tasks, the whole query is run inside the
interactive job, regardless of how the system value is set.
How close to the threshold can a system get without disrupting performance?
The answer depends on the dynamics of the workload, the percentage of work that is in queries, and the
projected growth rate. It also may depend on the number of processors and the overall capacity of the
interactive feature installed. For example, a job that absorbs a substantial amount of interactive CPU on a
uniprocessor may easily exceed the threshold, even though the "normal" work on the system is well under
it. On the other hand, the same job on a 12-way can use at most 1/12th of the CPU, or 8.3%. a single,
intense transaction may exceed the limit for a short duration on a small system without adverse affects,
but on a larger system the chances of having multiple intense transactions may be greater.
With all these possibilities, how much of the Interactive feature can be used safely? A good starting point
is to keep the average utilization below about 70% of the threshold value (Use double the threshold value
for the servers and earlier Model 170 systems that use the 1/3 algorithm described earlier in this
document.) If the measurement mechanism averages the utilization over a 15 minute or longer period, or
if the workload has a lot of peaks and valleys, it might be worthwhile to choose a target that is lower than
70%. If the measurement mechanism is closer to real-time, such as with Management Central, and if the
workload is relatively constant, it may be possible to safely go above this mark. Also, with large
interactive features on fairly large processors, it may be possible to safely go to a higher point, because
the introduction of workload dynamics will have a smaller effect on more powerful systems.
As with any capacity-related feature, the best answer will be to regularly monitor the activity on the
system and watch for trends that may require an upgrade in the future. If the workload averages 60% of
the interactive feature with almost no overhead, but when observed at 65% of the feature capacity it
shows some limited amount of overhead, that is a clear indication that a feature upgrade may be required.
This will be confirmed as the workload grows to a higher value, but the proof point will be in having the
historical data to show the trend of the workload.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 2 - Server Performance Behavior 31