Measure Reference Manual

ServerNet environment, you can have active requests in the read queue and write queue at
the same time. Therefore, some overlap can exist between the READ-QBUSY-TIME and
WRITE-QBUSY-TIME counters, and adding their values does not produce an accurate busy-time
measurement.
• The 64-bit byte-count fields (fields ending in -F) collect the same data as older 32-bit byte-count
fields. For example, the 64-bit field INPUT-BYTES-F collects the same data as the 32-bit field
INPUT-BYTES. The 64-bit fields are less subject to overflow caused by high levels of I/O activity.
The 32-bit fields are currently active and continue to return values. If no field overflow occurs,
the 32-bit fields and the 64-bit fields return the same value. If a 32-bit field overflows, the
corresponding 64-bit field returns the correct value, and the 32-bit field returns a value of -1.
The ERROR field for the measured entity also returns -1 to indicate an overflow condition.
Convert your applications to use the 64-bit fields; 32-bit fields might be deactivated in a future
PVU.
In MEASCOM commands and in command (OBEY) files, use the names of the 32-bit fields.
For example, issue the command LIST DEVICE BY INPUT-BYTES, not LIST DEVICE BY
INPUT-BYTES-F. MEASCOM uses the names of the 32-bit fields in output displays such as
reports and plots.
• Direct bulk I/O requests are counted as read and write requests to the disk. READ-BUSY-QTIME,
READ-QTIME, INPUT-BYTES, and similar counters are updated for both direct bulk I/O and
standard I/O.
If a disk is used for both standard and direct bulk I/O, you cannot determine the byte counts
for direct bulk I/O from the DISC counters alone. A detailed analysis of the FILE records for
each application process requesting DBIO transfers could provide this information.
• The 32-bit CN[N].BLKS field collects the same data as the older 16-bit C[N].BLKS field. If no
field overflow occurs, the 16-bit and the 32-bit fields return the same value. If a 16-bit overflows,
the corresponding 32-bit field returns the correct value, and the 16-bit field returns a value of
-1. The ERROR field for the measure entity returns -2 to indicate an overflow condition.
• In Measure G08 and later PVUs, new counters better evaluate the effectiveness of DP2’s mixed
workload algorithm in application processing and in assignment of process priorities. Measure
G08 counters (DEFREQS, DEFREQ-QLEN-MAX, DEFERRED-QTIME, DEFERRED-QLEN-MAX)
track the request time and deferred time for requests subject to deferral.
The mixed workload design gives you some control over the impact of running a low-priority
SQL query concurrently with high-priority workloads. The lower the priority of the SQL query,
the less impact to the high-priority response time. The speed of the query is also reduced as
the priority is reduced, especially for a parallel query that has multiple volumes in the same
CPU.
User control over this mixed workload is accomplished by query deferral when concurrent
higher priority workloads are active for the volumes. This deferral is small at priority 150 and
increases as the priority of the query is reduced. To disable the deferral, run the query at a
priority greater than 150.
The Measure counters for deferrable q-time and deferred q-time provide some indication of
the amount of deferral. If the SQL query requires too much time to complete, you see a high
ratio between deferrable q-time and deferred q-time. If response time increases significantly
during low-priority SQL query activity, you see a low ratio between deferrable q-time and
deferred q-time. Priority adjustments for the SQL query should correspond to changes in the
ratio.
Changes in platform or application might require some adjustments in the priority ad-hoc SQL
query activity. The design does not defer query activity until the query has processed some
minimal amount of data. However, some OLTP-type SQL query applications might need to run
above priority 150 to avoid deferral.
DISC 207