This document contains suggestions to avoid unnecessary SRB/TCB switches and reduce CPU overhead for zIIP support and to improve the offload to the ZIIP.
Note
You can use the Component Switch
Statistics (see the Natural system command
ZIIP) to view the list of components that cause TCB
switches.
The Natural profile/session parameter
MT (maximum
CPU time) has the effect that each time Natural starts a program at Level 1, a
z/OS timer service request must be executed. This forces Natural to switch off
from the zIIP. The default setting is MT=60 to prevent endless
loops in Natural applications. Consequently, each time Natural falls back to a
program level of 0, the timer is restarted. This also happens with the
FETCH statement: each time a program is fetched, the timer must be
reset.
The default setting is MT=60 to prevent endless loops
in Natural applications. Software AG recommends to set MT=0 when
running a session that executes many FETCH statements. This will
prevent Natural from using timer macros and avoids unnecessary SRB/TCB
switches.
Natural needs to switch off zIIP usage each time a 3GL program is executed, because Natural does not know whether any z/OS service calls are issued in the external subprogram(s).
In addition, Natural is only allowed to offload Natural-written code to a zIIP. User-defined code written in any other language must not be offloaded.
Calling 3GL programs within a Natural loop, forces many SRB/TCB switches, and therefore much CPU overhead. A high share of 3GL code will reduce the offload capabilities of Natural sessions. Such sessions are not suitable for running zIIP-enabled.
Executing an Adabas access statement in Natural, causes at least one WAIT SVC call and forces Natural to switch off from the zIIP. You can reduce the number of switches by exploiting the multi-fetch capabilities of Natural:
| Without Multi-Fetch | With Multi-Fetch | |
|---|---|---|
| Records read | 100,000 | 100,000 |
| Number of switches into SRB mode | 100,000 | 12,500 |
| Total enclave CPU time | 5,389 ms | 958 ms |
For further information on the multi-fetch feature, see Multi-Fetch Clause, in Accessing Data in an Adabas Database in the Programming Guide.
External sorts cannot be processed on zIIP. Therefore, Natural must deactivate zIIP when sending or receiving records from external sorts. In contrast, Natural sorts are processed exclusively on zIIP. Therefore, choosing a Natural sort over an external sort can boost zIIP utilization.
The following example illustrates the difference in zIIP utilization between a Natural sort and an external sort.
| External Sort | Natural Sort | External Sort | Natural Sort | |
|---|---|---|---|---|
| Records sorted | 12,500 | 12,500 | 25,000 | 25,000 |
| Enclave GP time | 95 ms | 3 ms | 141 ms | 4 ms |
| Enclave zIIP time | 71 ms | 121 ms | 134 ms | 259 ms |
| Total enclave CPU time | 166 ms | 124 ms | 275 ms | 263 ms |
| Number of switches into SRB mode | 211 | 0 | 419 | 0 |
Here is a sample Natural profile parameter SORT configuration that
bypasses external sorting and utilizes Natural:
SORT=(WRKSIZE=1000,EXT=OFF)
An increase in the number of switches into SRB mode significantly impacts the
performance of external sorting. You can mitigate unnecessary SRB/TCB switches by
configuring a sort work buffer as a cache buffer using the WRKSIZE keyword
subparameter of the Natural SORT profile parameter.
In the input phase of external sorting, Natural collects an adequate number of input records that fit into the work buffer and sends them to the external sort with just one SRB/TCB switch. Similarly, during the output phase of external sorting, Natural retrieves the appropriate number of sorted records that can fit into the work buffer with a single SRB/TCB switch.
The following example illustrates how the number of SRB/TCB switches involved in
external sort processing decreases as the WRKSIZE buffer values increase.
| WRKSIZE=10 | WRKSIZE=100 | WRKSIZE=1000 | |
|---|---|---|---|
| Records sorted | 25,000 | 25,000 | 25,000 |
| Number of switches into SRB mode | 419 | 41 | 5 |
| Enclave GP time | 143 ms | 135 ms | 131 ms |
| Enclave zIIP time | 158 ms | 151 ms | 147 ms |
| Total enclave CPU time | 301 ms | 286 ms | 278 ms |
Here is an example of the Natural profile parameter SORT, which enables
external sorting with a WRKSIZE buffer size of 1000 KB.
SORT=(WRKSIZE=1000,EXT=ON)
Any work file or printer usage causes I/O interrupts which force Natural to switch off from the zIIP. You can avoid unnecessary switches by defining cache buffers to be used for print and work file I/O processing. These cache buffers are used to keep the data in core as long as possible and read or write data in larger chunks.
The cache buffers are defined with the keyword subparameter
PWCSIZE
of the profile parameter ZIIP, for example:
ZIIP=(PWCSIZE=(300,200,300))
The buffer sizes are interpreted in KB. They specify the print buffer, read buffer and write buffer. Buffer sizes of several 100 KB are sufficient.
Primary I/O operations are not subject to caching. Instead, the size of the terminal
I/O buffer is relevant. This buffer is flushed either when it is full or when an I/O
operation is triggered by an INPUT statement.
You can use the Natural profile parameter
MAINPR to
separate program output from Natural system output and reroute primary output
for CMPRINT to an additional printer that is processed with a
cache buffer.
When your application creates a printout with a line size of 132 characters, a print cache of 132 KB will reduce the SRB/TCB switches for printing by a factor of 1000. This means, Natural will not switch for every line, but only once per 1000 lines or 20 pages.
| WRITE (1) Without Cache | WRITE (1) With Cache | |
|---|---|---|
| Lines written | 10,000 | 10,000 |
| Number of switches into SRB mode | 10,003 | 10 |
| Total WLM enclave CPU time | 386 ms | 68 ms |
For the work file handling, you will get a similar result:
| READ WORK FILE (1) Without Cache | READ WORK FILE (1) With Cache | |
|---|---|---|
| Records read | 10,000 | 10,000 |
| Number of switches into SRB mode | 10,478 | 5 |
| Total WLM enclave CPU time | 641 ms | 305 ms |
You can monitor the usage of the cache buffers by using the
Natural system command BUS.
To monitor buffer cache usage
Issue the following system command:
BUS
A Buffer Usage Statistics report then outputs the sizes used by the cache buffers:
12:50:28 ***** NATURAL BUS UTILITY ***** 2012-04-03 User SAG - Buffer Usage Statistics - OpSYS z/OS No. Name Type Size Used Perc. MaxUsed Perc. MaxSize Perc. ------------------------------------------------------------------------------ 18 PCACHE V 512000 32 0.0 511958 100.0 21 WCACHEO V 307200 32 0.0 306947 99.9 26 WCACHE01 V 512000 32 0.0 511992 100.0 ------------------------------------------------------------------------------ ThrdSize Total 1382656 166593 12.0 2000 54.9 33480 1.6 2000K (in KB) 1351K 163K 742K 33K ------------------------------------------------------------------------------ Nat9995 Natural session terminated normally. |
PCACHE is the cache for all print
output.
WCACHEO is the cache for the WRITE
WORK FILE statement.
WCACHEnn is the
cache for the READ WORK FILE statements.
For statements generating output (such as WRITE or
WRITE WORK FILE), only one cache buffer is allocated, also for
multiple files. For the READ WORK FILE statement, there is one
buffer allocated per work file. The buffers are allocated only when used.
For detailed information on the Buffer Usage Statistics, refer to the relevant section in SYSTP Utility in the Utilities documentation.
In batch mode and under TSO, Natural usually allocates an internal
buffer with a GETMAIN or FREEMAIN requests to the
operating system. Any storage request includes an SVC (supervisor call) and
requires a switch back to TCB processing mode.
You can reduce the number of GETMAIN or
FREEMAIN requests by specifying a thread size with the Natural
profile parameter THSIZE. Natural
will then allocate the specified amount of space with one GETMAIN
and then serve all buffer requests from the allocated thread storage without
calling the operating system again.
At the end of a Natural session, you can use the
Buffer
Usage Statistics report (see the
example screen) to check the
buffer and thread usage and determine whether the defined thread size
(MaxUsed) is sufficient to allocate all buffers used by the
session.
