By Laurence Hart
Software Developer
IBM Tivoli System z software
z/OS (V1.7 and higher) on the IBM System z10 implements a new approach to dispatching work called HiperDispatch to address IBM customers’ increasing workload demand for processor cycles and high speed memory access. With the HiperDispatch feature, z/OS can attempt to re-dispatch a unit of work repeatedly on the same physical CPU, or collection of physically adjacent CPUs (an affinity node), to increase the chances of obtaining data from processor L1, L1.5 or L2 cache, instead of incurring a time delay by going to main memory.
Laurence Hart’s first article in this two-part series introduced the HiperDispatch technology. This concluding article describes how IBM Tivoli OMEGAMON XE on z/OS can help you better understand the actions of HiperDispatch under z/OS.
|
IBM Tivoli OMEGAMON XE on z/OS Version 4.1 (with PTFs UA39283 and UA39284, and APARs OA23220 and OA23223) supports the HiperDispatch feature through the workstation-based Tivoli Enterprise Portal and the 3270-based Tivoli OMEGAMON classic interface. The two interfaces provide essentially the same HiperDispatch status details and statistics, including:
- LPAR current HiperDispatch status: on, off or not applicable.
- Names of the logical partition (LPAR), LPAR cluster and LPAR group, if available.
- Current, minimum and maximum LPAR weights (z/OS intelligent resource director feature) for standard central processors (CPs), IBM System z Application Assist Processor engines (zAAPs) and IBM System z Integrated Information Processor engines (zIIPs).
Further, for each logical CP (LCP) – grouped by standard CP, zAAP and zIIP – these interfaces provide:
- Logical CPU ID
- HiperDispatch priority: high, medium or low
- Percentage share of the physical processor guaranteed to the LCP
- Physical processor dispatch utilization as a percentage
- Physical processor LPAR overhead as a percentage
- HiperDispatch status: online, offline, parked, park pending or reserved.
System CPU Utilization and HiperDispatch Details workspaces
The System CPU Utilization workspace in IBM Tivoli OMEGAMON XE for z/OS, shown in Figure 1, provides a new link that lets you navigate to a new HiperDispatch Details workspace. A new column in the System CPU Utilization workspace indicates the LPAR’s HiperDispatch status: on, off or N/A. N/A indicates the system lacks the required level of operating system and hardware support.
Figure 1: System CPU Utilization workspace showing the HiperDispatch Management status column and a new link to the HiperDispatch Details workspace.
Selecting the HiperDispatch Details link navigates you to the HiperDispatch Details workspace, which contains separate panes for standard, zAAP and zIIP LCPs with LCP-level details. Another pane displays the LPAR name, LPAR cluster name and LPAR group name. LPAR current, minimum and maximum weights by standard, zAAP and zIIP processor type are displayed in another pane.
The LPAR attributes and LPAR weights panes (Figure 2) shows that HiperDispatch is activated in LPAR JB0 in LPAR cluster UTCPLXJ8. LPAR JB0 is not a member of an LPAR group, so N/A is displayed.
The LPAR weights pane shows the LPAR weighting for each processor type: standard, zAAP and zIIP. Since the minimum and maximum weights present a range of values,
z/OS workload management (WLM) weight management is active through the intelligent resource director feature. The LPAR weights are used by HiperDispatch to allocate HiperDispatch high- and medium-share percentages for each processor.
Figure 2: The HiperDispatch Details workspace displays LPAR attributes and LPAR weights.
Figure 3 shows the standard logical processors pane. In this example, the HiperDispatch details for LPAR JB0 include six high- and two medium-share standard LCPs. The complex calculation for the number of high standard LCPs, which is based on the LPAR weights, yielded 7.368. This result would have generated a single medium LCP with a percentage share of a physical processor of 36.8 percent, but because it is below 50 percent, a high LCP was converted to a medium LCP and the combined percentage share of 136.8 was divided equally between two medium processors. The resulting percentage share for each of the two medium processors is 68.4 percent. (For more details on HiperDispatch calculations, see Part 1.
Tivoli OMEGAMON for z/OS shows:
- Six high-share and two medium-share standard LCPs were driven at high utilizations in at an average of 90-96 percent during the measured interval (enter to enter).
- Eight of the low-share LCPs were unparked and performed at 88-92 percent utilization during the same interval.
- Eight of the low LCPs were online at the end of the interval, while the other seven were parked.
- LPAR management overhead for each LCP is displayed.
Additional processors configured to this partition may be viewed by using the scroll bar to the right of the pane.
Figure 3: The HiperDispatch Details workspace includes this standard logical processors pane.
Figure 4 shows the zAAP logical processors and zIIP logical processors panes. Any processors configured as reserved will be displayed, as shown below. These LCPs have not been varied online to this LPAR (e.g. using the VARY CPU console command) during the current initial program load (IPL), so they show as reserved instead of offline.
The two zIIP LCPs are designated medium with 55.0 percent share, because the LPAR weight-based calculation yielded a result of 1.10. Since a medium LCP with a share of 10 percent is inefficient, the high LCP is designated a medium LCP and the combined share percentages divided equally at 55.0 percent between the two LCPs.
Figure 4: The HiperDispatch Details workspace includes zAAP logical processors and zIIP logical processors panes.
You can also configure historical reporting for these workspaces to obtain the detailed and summarized behavior of HiperDispatch over a future time interval.
3270-based SYS major ENV minor command
Within the 3270-based classic interface, the ENV minor command of the SYS major command now includes HiperDispatch status. If a platform supports HiperDispatch, the status is displayed as on or off. If a platform does not support the feature, the HiperDispatch management literal will not appear in the output. (Figure 5)
Figure 5: SYS major ENV minor command displays the HiperDispatch management status view.
3270-based HDSP immediate command
HiperDispatch statistics and data are available through a preset menu or by entering a command directly in a Tivoli OMEGAMON 3270-based free-format screen space. Selecting the CPU option on the 3270-based Tivoli OMEGAMON menu displays the sub-menu screenspace ZUTIL, which now includes a HiperDispatch option, as shown in Figure 6.
Figure 6: ZUTIL processor menu screenspace.
Selecting the HiperDispatch option will navigate to ZHDSP, the HiperDispatch statistics and status screen space shown in Figure 7.
Figure 7: HiperDispatch statistics are grouped by standard, zAAP and zIIP LCPs in the ZHDSP HiperDispatch statistics and status screenspace.
Using Tivoli OMEGAMON XE on z/OS HiperDispatch support
The earlier Figure 4, and Figure 8 below, show online zAAP LCPs associated with an oddity: a share value of 137.5 percent – a weight greater than the physical CPU resource can deliver. Tivoli OMEGAMON helps reveal the situation.
Figure 8: Tivoli OMEGAMON reveals the effects of overweighting an LPAR.
The overweighting arises because the LPAR has an allocation from the pool of shared physical zAAPs based on the zAAP LPAR weight of 550. The total weight across all non-dedicated LPARS is 1000, so this LPAR is allocated 550/1000 or 55 percent of the shared physical zAAPs.
There are five shared physical zAAPs in the complex, so the LPAR is given 55 percent of 5 or 2.75 guaranteed physical zAAPs. Two zAAP LCPs are configured to the LPAR, so each shows up as a high-share zAAP LCP with a 137.5 percent share.
Obviously, this anomaly requires that the LPAR’s zAAP weighting relative to others in the complex, or the number of zAAP LCPs configured to the LPAR, be adjusted. Given that this LPAR is configured with two zAAP LCPs on standby, it’s possible that varying one, or both, of them online to the LPAR is a suitable course of action.
Tivoli OMEGAMON details in Figure 8 above also show that online zAAPs are consuming an average of 98 percent between them, which suggests that the LPAR currently has inadequate zAAP resources. Using another Tivoli OMEGAMON command, LPAR, we can determine if complex-wide utilization of physical zAAP resource allows varying of one or more of the standby zAAP LCPs online to the LPAR, without impacting the zAAP performance of other LPARs’ workloads.
Impact of HiperDispatch on the existing MCPU command output
A side-effect of an active HiperDispatch feature may be seen in the output of the existing OMEGAMON 3270 interface MCPU command, as shown in Figure 9. Individual LCPs are shown on the right revealing that four of the 19 online standard LCPs – CPU00 through CPU12 – have zero utilization.
Figure 9: A ZMCPU screenspace shows the effect of HiperDispatch on CPU utilization distribution.
Zero utilization of some processors arises because HiperDispatch is dispatching its workloads on the 15 processors that can currently accommodate the work before unparking one of the four parked processors – to maximize the Level 2 processor cache utilization.
As workload CPU demands vary, an operator can typically observe fluctuations in the number of parked processors while the processors remaining online in high, medium and unparked low status typically run at high utilizations.
Summary
The HiperDispatch feature on the IBM System z10 can be deployed on one or more LPARs in a complex, either through SYS1.PARMLIB controls or dynamically through an operator command. The feature achieves performance improvements by maximizing processor caching efficiency through cooperation between the IBM System z10 hardware, Processor Resource/System Manager (PR/SM) and z/OS. This approach takes advantage of physical processor topology information exposed through Store System Information (STSI) enhancements on System z10 to boost CPU performance as much as 10 percent. Very large, memory intensive workloads running on large numbers of physical processors (16 to 64) are most likely to achieve the highest performance gains.
IBM Tivoli OMEGAMON XE on z/OS Version 4.1 with maintenance PTFs provides extensive statistics related to HiperDispatch through both the Tivoli Enterprise Portal and 3270-based interfaces. These statistics help users determine the current HiperDispatch configuration details and how HiperDispatch impacts CPU resource utilization within an LPAR.
|
