An IBM® System z® server can be configured with optional processors known as specialty engines (SEs), which are slightly modified standard processors that are designed to offload eligible workloads from general-purpose (GP) processors. Some of the CPU processing that would otherwise be executed on GP processors can, under certain conditions, be executed on an SE.
IBM z/OS® Integrated Information Processors (zIIPs) can help to dramatically reduce total cost of ownership (TCO) for System z mainframes because the workloads executed on them is not considered part of the price of the software. In addition, the purchase price of a zIIP is usually quite a bit lower than a standard processor.
zIIPs were introduced in 2006 as part of IBM System z9® hardware and designed to work with IBM DB2® for z/OS Version 8. Since then, the number of DB2-eligible workloads has been growing steadily. Several zIIP-related improvements were included with DB2 10 for z/OS, and it seems likely that the next version of DB2 for z/OS will provide even more zIIP support.
Up to 60 percent of the CPU used in DB2 10 for z/OS by distributed access through TCP/IP and distributed relational database architecture (DRDA) can be offloaded. This functionality has been retrofitted to DB2 V8 and V9.
zIIP offload capabilities built into DB2 10 include:
DB2 for z/OS is not the only software that can offload CPU to zIIPs; many software products from IBM and other vendors can take advantage of these SEs as well. The z Application Assist Processor (zAAP) specialty engines are similar to zIIPs, but they are dedicated to running specific Java and XML workloads on z/OS. Version 1.11 of z/OS introduced a feature that allows users to run zIIP- and zAAP-eligible workloads on installed zIIP processors.
Configurations where the number of zIIPs is low compared with the number of standard processors are not uncommon. This imbalance is not necessarily a problem if the available number of zIIPs is enough to handle the eligible workload. But given the trend of ever-increasing eligible workloads, the stress on zIIP engines tends to grow over time.
The z/OS operating system dispatches eligible workloads to zIIPs for execution. If the zIIP is too busy, it can call for help from standard processors to complete a piece of work. When the system parameter IIPHONORPRIORITY is set to YES, it specifies that a standard processor can run zIIP-eligible work if called by a zIIP processor. This portion of CPU is often referred to as SE-eligible processor time executed on standard processor. This time is reported on resource management facility (RMF) records, for example, and can be used as a capacity-planning metric because it indicates that the system may benefit from more zIIP capacity—when a zIIP has to ask for help from standard processors, the cost-effectiveness of the overall system suffers.
Although zIIPs can offload eligible workloads to standard processors, calling in this assistance can slow down the workload. The system parameter ZIIPAWMT specifies an alternate wait management (AWM) value for zIIPs. By default (when HIPERDISPATCH=YES, a recommended system parameter value for performance), this means that a transaction may have to wait for up to 3.2 milliseconds before it receives help from standard processors.
Some users have reported processes that ran smoothly in previous versions of DB2 experience significant performance degradation with DB2 10 for z/OS. This degradation is a consequence of too little zIIP capacity and the delays incurred when the zIIPs require help from standard processors. This observation would be even more noticeable for the same scenario running with IIPHONORPRIORITY set to NO, which would prevent the zIIPs from receiving assistance from standard processors.
The potential problems related to a low zIIP capacity can be exacerbated by the DB2 10 capacity to offload more CPU to zIIP engines. Although there are a few workarounds to this situation, the appropriate design decision is to add more zIIP capacity to the logical partition (LPAR).
Experience has shown that keeping zIIP utilization at approximately 50 percent or less helps avoid processing delays. For DB2 SQL-intensive LPARs (for example, a data warehouse environment), you get the best performance when the number of zIIPs matches the number of standard processors.
Does your company use zIIPs in your environment? What kind of performance degradation do you see when zIIPs call on standard processors for help? Please share your experiences in the comments.