164 lines
10 KiB
HTML
164 lines
10 KiB
HTML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE html
|
||
|
|
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
||
|
|
<html lang="en-us" xml:lang="en-us">
|
||
|
|
<head>
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||
|
|
<meta name="security" content="public" />
|
||
|
|
<meta name="Robots" content="index,follow" />
|
||
|
|
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
|
||
|
|
<meta name="DC.Type" content="concept" />
|
||
|
|
<meta name="DC.Title" content="Reporting CPU utilization" />
|
||
|
|
<meta name="abstract" content="Find out how the total CPU that is consumed across virtual processors is reported." />
|
||
|
|
<meta name="description" content="Find out how the total CPU that is consumed across virtual processors is reported." />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzahxperftoolsconcepts.htm" />
|
||
|
|
<meta name="DC.Relation" scheme="URI" content="rzahxqapmsyscpu.htm" />
|
||
|
|
<meta name="copyright" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 1998, 2006" />
|
||
|
|
<meta name="DC.Format" content="XHTML" />
|
||
|
|
<meta name="DC.Identifier" content="rzahxcalculation" />
|
||
|
|
<meta name="DC.Language" content="en-us" />
|
||
|
|
<!-- All rights reserved. Licensed Materials Property of IBM -->
|
||
|
|
<!-- US Government Users Restricted Rights -->
|
||
|
|
<!-- Use, duplication or disclosure restricted by -->
|
||
|
|
<!-- GSA ADP Schedule Contract with IBM Corp. -->
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
|
||
|
|
<link rel="stylesheet" type="text/css" href="./ic.css" />
|
||
|
|
<title>Reporting CPU utilization</title>
|
||
|
|
</head>
|
||
|
|
<body id="rzahxcalculation"><a name="rzahxcalculation"><!-- --></a>
|
||
|
|
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
|
||
|
|
<h1 class="topictitle1">Reporting CPU utilization</h1>
|
||
|
|
<div><p>Find out how the total CPU that is consumed across virtual processors
|
||
|
|
is reported.</p>
|
||
|
|
<p>Prior to V5R3, processor utilization was calculated as a percentage of
|
||
|
|
the available CPU time. Collection Services reported, in the performance database
|
||
|
|
files, the time used on each processor along with elapsed interval time. Users
|
||
|
|
of this data, such as the Performance Tools reports and displays, needed to
|
||
|
|
add up the time used on each processor to get the total system CPU that was
|
||
|
|
consumed. The available CPU time was calculated as the number of processors
|
||
|
|
in the partition multiplied by the duration of the data collection interval.
|
||
|
|
Finally, the CPU time was divided by the calculated available time to get
|
||
|
|
the utilization percentages.</p>
|
||
|
|
<p>The problem with the previous methodology is that all users of the data
|
||
|
|
assumed whole virtual processors and depended on no changes to the configured
|
||
|
|
capacities. Logical partitions with partial processor capacities and the capability
|
||
|
|
to do dynamic configuration no longer worked with this methodology. Temporary
|
||
|
|
solutions for minimizing the impacts of these problems included scaling the
|
||
|
|
utilization of the system processors to what would be reported for a whole
|
||
|
|
number of processors and cycling Collection Services when the configuration
|
||
|
|
changed. Because the individual job CPU time was not scaled, the additional
|
||
|
|
time was accounted for by reporting it as being consumed by HVLPTASK. The
|
||
|
|
HVLPTASK task did not actually use CPU, but CPU time was shown to be consumed
|
||
|
|
by HVLPTASK for accounting purposes. The CPU time charged to HVLPTASK scaled
|
||
|
|
the amount of work that was done by real jobs, which resulted in the system
|
||
|
|
CPU percent utilization going from 0 to 100 in direct proportion to the amount
|
||
|
|
of customer work that was performed.</p>
|
||
|
|
<p>In V5R3, Collection Services reports the total CPU that is consumed and
|
||
|
|
the total CPU that is available to the partition within the interval. The
|
||
|
|
concept of HVLPTASK and CPU scaling to whole virtual processors in shared
|
||
|
|
processor environments does not exist. Collection Services no longer cycles
|
||
|
|
the collection when the configuration changes.</p>
|
||
|
|
<p>Collection Services now reports the total processor time that is consumed
|
||
|
|
by the partition along with the amount of processor time that was available
|
||
|
|
to be consumed within the partition, regardless of the number of virtual processors
|
||
|
|
that are configured, the partition units that are configured, or how they
|
||
|
|
changed during the interval. To calculate utilization, users of this data
|
||
|
|
divide the reported CPU consumed by the available capacity. This method of
|
||
|
|
calculating CPU utilization eliminates the increasingly error-prone task of
|
||
|
|
computing available CPU time. CPU utilization that is calculated with these
|
||
|
|
new metrics is accurate regardless of how many processing units (whole or
|
||
|
|
fractional) exist, when the processing units changed, or how often the units
|
||
|
|
changed.</p>
|
||
|
|
<p>Several reasons account for this change in calculating CPU utilization.
|
||
|
|
One reason is that with scaling utilization for jobs or groups of jobs appeared
|
||
|
|
to be much smaller than would be anticipated. This concept is demonstrated
|
||
|
|
in the example that follows. Another reason is that a configuration change
|
||
|
|
could make CPU reporting not valid. Traditionally, the number of CPUs was
|
||
|
|
based on the value that was configured at the beginning of a collection and
|
||
|
|
an IPL was needed to change it. When dynamic configuration was introduced,
|
||
|
|
Collection Services cycled the collection to handle the configuration changes,
|
||
|
|
which assumed that changes would be infrequent. However, the more frequent
|
||
|
|
the change, the more cycling occurs. If the changes are too frequent, collecting
|
||
|
|
performance data is not possible. Lastly, even if the proper configuration
|
||
|
|
data were reported and used for every interval, you would not know what happened
|
||
|
|
between the time the interval started and until it completed. Utilization
|
||
|
|
would still be calculated incorrectly in any interval where there was one
|
||
|
|
or more configuration changes.</p>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Example</h4><p>Partition A has a capacity of 0.3 processor
|
||
|
|
units and is defined to use one virtual processor. The collection interval
|
||
|
|
time is 300 seconds. The system is using 45 seconds of CPU (15 seconds by
|
||
|
|
interactive jobs and 30 seconds by batch jobs). In this example, the available
|
||
|
|
CPU time is 90 seconds (.3 of 300 seconds). The total CPU utilization is 50%.</p>
|
||
|
|
<p>Prior
|
||
|
|
to V5R3, when the numbers were scaled, system CPU usage is reported as 150
|
||
|
|
seconds. 150 seconds divided by 300 seconds of interval time results in 50%
|
||
|
|
utilization. The interactive utilization is 15 seconds divided by 300 seconds,
|
||
|
|
which is 5%. The batch utilization is 30 seconds divided by 300 seconds, which
|
||
|
|
is 10%. The HVLPTASK is getting charged with 35% utilization (150 seconds
|
||
|
|
minus 45 seconds), or 105 seconds divided by 300 seconds. These percentages
|
||
|
|
give us a total of 50%.</p>
|
||
|
|
<p>Beginning in V5R3, the 45 seconds of usage is
|
||
|
|
no longer scaled but is reported as is. The calculated CPU time that is derived
|
||
|
|
from the reported consumed CPU time divided by the reported available capacity
|
||
|
|
is 50% (45 seconds divided by 90 seconds). The interactive utilization percentage
|
||
|
|
is 17% (15 seconds divided by 90 seconds). The batch utilization percentage
|
||
|
|
is 33% (30 seconds divided by 90 seconds).</p>
|
||
|
|
|
||
|
|
<div class="tablenoborder"><table cellpadding="4" cellspacing="0" summary="" frame="border" border="1" rules="all"><thead align="left"><tr><th valign="top" id="d0e43">Release</th>
|
||
|
|
<th valign="top" id="d0e45">Total CPU</th>
|
||
|
|
<th valign="top" id="d0e47">Interactive</th>
|
||
|
|
<th valign="top" id="d0e49">Batch</th>
|
||
|
|
<th valign="top" id="d0e51">HVLPTASK</th>
|
||
|
|
</tr>
|
||
|
|
</thead>
|
||
|
|
<tbody><tr><td valign="top" headers="d0e43 ">OS/400 V5R2 or earlier</td>
|
||
|
|
<td valign="top" headers="d0e45 ">50%</td>
|
||
|
|
<td valign="top" headers="d0e47 ">5%</td>
|
||
|
|
<td valign="top" headers="d0e49 ">10%</td>
|
||
|
|
<td valign="top" headers="d0e51 ">35%</td>
|
||
|
|
</tr>
|
||
|
|
<tr><td valign="top" headers="d0e43 ">OS/400<sup>®</sup> V5R3
|
||
|
|
or later</td>
|
||
|
|
<td valign="top" headers="d0e45 ">50%</td>
|
||
|
|
<td valign="top" headers="d0e47 ">17%</td>
|
||
|
|
<td valign="top" headers="d0e49 ">33%</td>
|
||
|
|
<td valign="top" headers="d0e51 ">N/A</td>
|
||
|
|
</tr>
|
||
|
|
</tbody>
|
||
|
|
</table>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div class="section"><h4 class="sectiontitle">Considerations</h4><p>In V5R3, the <span class="cmdname">Convert Performance
|
||
|
|
Data (CVTPFRDTA)</span> command performs normally. However, the data in
|
||
|
|
the converted files is changed to be consistent with the unscaled system CPU
|
||
|
|
data (QAPMSYSCPU database file). The results should be the same as if the
|
||
|
|
data were collected on a V5R3 system, but the data is different than the values
|
||
|
|
that existed in the files in a prior release.</p>
|
||
|
|
<p>The existing and unchanged
|
||
|
|
tools that calculate CPU utilization do not show the correct results for shared
|
||
|
|
processor partitions or partitions that have had configuration changes during
|
||
|
|
data collection. This includes those tools that use the performance database
|
||
|
|
as well as those that use the <span class="apiname">QPMLPFRD</span> API.</p>
|
||
|
|
<p>You can
|
||
|
|
copy a V5R3 management collection object (*MGTCOL) to a prior release and
|
||
|
|
generate the database files. However, you should be aware of the following:</p>
|
||
|
|
<ul><li>The reported CPU data remains unscaled (shared processor environments).
|
||
|
|
This means that the total system CPU that is reported by the tools using virtual
|
||
|
|
processors (including Performance Tools) is not correct.</li>
|
||
|
|
<li>A management collection object (*MGTCOL) that spans configuration changes
|
||
|
|
will result in an inaccurate calculation of the percentage of CPU during those
|
||
|
|
intervals after the change occurred. </li>
|
||
|
|
</ul>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
<div>
|
||
|
|
<div class="familylinks">
|
||
|
|
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzahxperftoolsconcepts.htm" title="Describes a variety of tools to help you collect and analyze performance information. Find detailed information about exactly which tools perform which functions and how they work.">Performance Tools concepts</a></div>
|
||
|
|
</div>
|
||
|
|
<div class="relinfo"><strong>Related information</strong><br />
|
||
|
|
<div><a href="rzahxqapmsyscpu.htm">Performance data files: QAPMSYSCPU</a></div>
|
||
|
|
</div>
|
||
|
|
</div>
|
||
|
|
</body>
|
||
|
|
</html>
|