HP 3000 Manuals

HP RXForecast Users Manual for MPE Systems

Examining a CPU Utilization Case 

For this example, you are going to look at the CPU Utilization of
Trapper.

You know before forecasting that the CPU should be upgraded to handle
workload growth.  What you would like to know is if the workload growth
would continue to grow if there were adequate resources at the CPU to
accommodate it.

The immediate goal is to determine if there has been steady growth in CPU
Utilization globally, and then specifically for Session CPU Utilization
and Job CPU Utilization.

RXForecast Options Selections 

For this example, choose from the RXForecast Options command dialog box
as follows:


            

   *   Seasonality Level.

       By default there should be a check mark in every seasonality box,
       including Auto Seasonality.

   *   Confidence Level.

       Set the confidence level to 90% Confidence.

   *   Interval Type.

       Choose Confidence Interval.

Forecast Selections 

Choose options from the Forecasts command dialog box as follows:

   *   Metric.

       Begin by looking at all three CPU metrics:

          *   Global CPU Utilization.

          *   Job CPU Utilization.

          *   Session CPU Utilization.

       You select multiple metrics by holding down Shift and clicking on
       each metric.

   *   X-Axis.

       Set the X-Axis to 6 months.

   *   Ignore Weekends.

       Check Ignore Weekends to exclude weekend data.

   *   Points Every.

       Choose Points Every Day.

   *   Shift.

       Choose a standard work day of 8 AM to 5 PM.

   *   Dates.

       Leave the start/stop days at the default so that the entire
       logfile is shown.

   *   Trending Method.

       For this first look at the data, select Smoothing.  This should
       show you a basic average of how the CPU is being utilized for each
       metric.

   *   Show Threshold.

       Click on  NEXT to verify that the Show Threshold option is set at
       0.

Resulting Graphs 

Run the model to get the following graphs:


            


            


            

Analysis 

If you look closely at different time periods in the graphs, you see that
in every case the utilization is fairly steady and may even decrease from
March through April.

Beginning in May, a steady growth takes place and lasts for approximately
2 months.  In July, growth subsides; notice the short downward trend.
Finally, in August utilization stabilizes again.

If you look at each metric individually, you see the following:

   *   Global CPU Utilization.

       Global CPU Utilization was running from 60-70 percent for the
       first 2 months.  It dipped for a short time, then climbed to an
       average of nearly 90 percent, dipped back down to 70 percent, and
       then settled back up at the 90 percent mark.

   *   Session CPU Utilization.

       Session CPU Utilization was stable at 8 percent until May, and
       then climbed over 15 percent to almost 20 percent, and then
       leveled off just under 15 percent.

   *   Job CPU Utilization.

       Job CPU Utilization was steady between 25-30 percent, dipped to 22
       percent, then climbed to over 30 percent, and settled at about 30
       percent.

Conclusions 

The system was running fairly steady for March and April, then there was
a steady increase of utilization for two months, followed by a period
when the utilization leveled off.

You know from experience that when Global CPU Utilization exceeds 70
percent the machine's performance may potentially suffer and response may
become more erratic.  You also know that it is impossible to utilize a
device over 100 percent.

This band of uncertain performance between 70 and 100 percent is what
causes longer response times at terminals and longer running batch jobs.

You can verify this expectation by looking at the response time graphs
for this logfile.  Close the open graphs and return to the Forecasts
command dialog box.  Change the metrics to First Response and Response to
Prompt.

Draw the following two graphs:


            

Notice that in early June these graphs show a dramatic increase in
response times.  The system appears bottlenecked on CPU. If the batch
jobs were unnecessary and could be rescheduled, you should see a dip in
Job CPU Utilization after the CPU exceeded 80 percent.  Since you see no
drop, those batch jobs must be important enough that with this increase
and the increase of the session load, response times have suffered.

This system will continue to experience erratic response times and the
CPU will remain above 80 percent until the workload mix is altered or the
CPU is upgraded.

Close the open graphs.

Reforecast 

Verify that the growth of the Job and Session CPU Utilizations is stunted
by CPU saturation by seeing how the actual data would compare to a
forecast generated by the data from May and June.

Return to the first steps in the forecasting process.

RXForecast Options Selections 

Change the following options in the RXForecast Options command dialog
box:

   *   Interval Type.

       To get a confidence interval with the widest spread possible,
       select Prediction Interval for the Interval Type.

Forecast Selections 

Make the following changes on the Forecasts command dialog box:

   *   Dates.

       Set the start date to May 2nd and the stop date to June 30th.
       Leave the validate date at the end (Last).

   *   X-Axis.

       Leave the X-Axis at 6 months.  With the Dates option, choose a
       time frame of 2 months.  Since the historic data spans only 2
       months, you would ideally forecast no more than another 2 months.
       The X-Axis option of 6 Months is the best fit to this 4-month
       ideal.

   *   Trending Method.

       Select the Linear method for forecasting.

Resulting Graphs 

Draw the following Global, Session, and Job graphs:


            


            


            

Analysis 

Look at the Session and Job graphs.  Notice that the actual data did not
grow as the forecast predicted.  If you check the Global CPU graph, you
will note that little or no growth was possible because the actual
utilization was very close to 100 percent.

Reforecast 

What else can you learn from this data?  From the preceding graphs, you
can see that CPU is saturated; you cannot add demand until you increase
the resource.  Close any open graphs.

Next generate a linear forecast for the CPU components.  Use all of the
data in the logfile.  Then verify its validity.

Return to the first steps in the forecasting process.

Forecast Selections 

   *   Dates.

       Move the start date to the beginning and the stop date to last.

   *   X-Axis.

       Change the X-Axis to Year since the time frame spanned by the
       dates is 6 months.

   *   Trending Method.

       Choose Linear.

Resulting Graphs 

Run the model again to get the following graphs:


            


            


            

Analysis 

Note that Week of Month seasonality has been detected and included in the
forecast for the Global CPU Utilization graph.  Investigate the validity
of these forecasts by reviewing the Stats reports.  The table below shows
the relevant numbers.

          Table 5-1.  Statistics 

                          |  Standard Error   |     R-Squared     |       T-Probability 
                          |                   |                   |     (slope/intercept) 
                          |                   |                   |
Global CPU                |       15.76       |       0.27        |          100/100
                          |                   |                   |
Session CPU               |       2.88        |       0.54        |          100/100
                          |                   |                   |
Job CPU                   |       6.02        |       0.07        |         100/99.6
                          |                   |                   |

The R-Squared statistics seem quite low (a value close to 1 is optimal);
while the Standard Error numbers are quite high (a value close to 0 is
optimal).  You expect to be able to obtain better results, so you
continue.

Reforecast 

If you look closely at the actual data, it shows that the points are
rather widely dispersed around the forecast and that two days have very
low utilizations.  An ideal forecast would show very little variation
between the actual data points and the forecast.  These two days--about
May 28th and July 4th--are U.S. holidays that, in 1988, did not fall on a
weekend.  This may be causing some of the error in the forecast.

Return to the first steps in the forecasting process.

Forecast Selections 

   *   Points Every.

       You can try to eliminate some of this variability by summarizing
       the data to the week (Points Every Week instead of Points Every
       Day), thus averaging these very low days with the other days in
       the week.

   *   Dates.

       Perhaps more importantly, you can use only May 2nd through June
       30th--a period of steady growth--to calculate the forecast.  You
       would like to see how much growth you could expect if adequate
       resource is available.  You know from the previous graphs that the
       workload growth was restricted by the lack of CPU resource.

   *   X-Axis.

       Since the data spans only 2 months, choose an X-Axis of 6 months.

Resulting Graphs 

Run the model with a weekly summary and use only May and June to
calculate the forecast.  The following figures show the new graphs:


            


            


            

Analysis 

Reviewing the statistics (Stats report) from these forecasts, you find
the following:

          Table 5-2.  Statistics 

                          |  Standard Error   |     R-Squared     |       T-Probability 
                          |                   |                   |     (slope/intercept) 
                          |                   |                   |
Global                    |       6.77        |       0.80        |         100/99.7
                          |                   |                   |
Session                   |       1.26        |       0.84        |         99.9/99.9
                          |                   |                   |
Job                       |       2.46        |       0.66        |         100/98.6
                          |                   |                   |

These values are far superior to the daily forecast and still provide
enough detail for this particular study.

On these graphs you notice that if the forecast became reality, the
following would occur:

   *   Global CPU Utilization.

       Global CPU Utilization would reach 100 percent by July.

   *   Session CPU Utilization.

       Session CPU Utilization would grow more slowly, but would rise
       from 8 percent to 30 percent by the end of October.

   *   Job CPU Utilization.

       Job CPU Utilization would grow to over 50 percent by the end of
       October--up from 23 percent in May.

       For a longer forecast, use 1 Year to see the end of the values.

A Final Note 

Using a higher level summary may not always be effective if too little
data exists to generate a good forecast.  In this case, because you have
8 weeks of data on which to base the forecast, using the higher level
summary worked quite well.  In other cases, there may not be enough weeks
after the summary, or the weekly summaries may be as dispersed as the
daily summaries.  By summarizing by the week, you also lose the high and
lows that are caused by Day of the Week seasonality.

MPE/iX 5.0 Documentation