PJ44591 - Dynamic CPU capacity
MarkLehrer 2700075VCH Comments (2) Visits (5846)
Dynamic CPU capacity provides support for you to immediately increase CPU capacity to achieve service level agreements (SLAs), and to run more workload on existing CPU hardware to lower costs.
Dynamic CPU capacity support has three parts:
1)Provides support for you to handle a sustained increase in workload without requiring an outage.
2)Provides support for HiperDispatch, which can help you to maximize CPU resources and lower hardware costs.
3)Provides support for you to selectively designate utilities as low priority so that you can run these utilities during peak traffic periods without impacting real-time transactions.
Add CPU capacity without requiring a processor outage
With dynamic CPU capacity, you can IPL a z/TPF logical partition (LPAR) with a large number of central processing units (CPUs) and restrict or cap the number of in-use CPUs. When demand increases, additional CPUs (referred to as I-streams in z/TPF) can be used by increasing the cap. An IBM Dynamic CPU for z/Transaction Processing Facility contract, which is an attachment to the IBM Z Capacity on Demand (CoD) offering, is available for z/TPF systems that run as a dedicated LPAR on an IBM z14 machine. This contract provides usage-based pricing for I-streams that are above the I-stream cap and can help reduce hardware costs.
If a z/TPF LPAR is running at a high utilization and you need additional capacity, there are two methods to increase capacity. One method is to increase the speed of the machine. For example, on a z14 with a 3906-510 processor, the speed of the machine can be increased from a 510 to 610 to 710. You can do this when the z/TPF system is running in NORM state.
The second method to increase capacity is to add I-streams. For example, when a z/TPF LPAR partition has 10 I-streams and the machine is a z14 with a 3906-722 processor, you can add more I-streams to the z/TPF LPAR partition. Before dynamic CPU capacity, an outage was required for the z/TPF system to recognize and use the additional I-streams.
With dynamic CPU capacity, you can IPL a z/TPF LPAR with more I-streams than you currently need and define an I-stream cap for the number of in-use I-streams. When additional capacity is needed, you can change the I-stream cap so that additional capacity can be added without an outage. For example, on a z14 with a 3906-722 processor, you can IPL a z/TPF LPAR with 16 I-streams and cap the LPAR at 10 I-streams. In this situation, the z/TPF system will use only 10 I-streams. As workload increases, you can add capacity by increasing the cap from 10 to 11 to 12, as high as 16.
If the z/TPF system is running as a dedicated LPAR on a z14, you can get usage-based pricing for the I-streams that are above the cap. In the previous example, if a dedicated z/TPF LPAR is IPLed with 16 I-streams and the cap is set to 10, there are 6 I-streams that are above the cap. When the IBM Dynamic CPU for z/Transaction Processing Facility attachment contract is in place, usage-based pricing is used for the 6 I-streams that are above the cap.
Support for HiperDispatch in z/TPF
HiperDispatch provides support to automatically expand or collapse the number of I-streams where the z/TPF system distributes work. HiperDispatch can be used only by shared LPAR partitions. The purpose is to improve the efficiency of I-streams that are shared across multiple LPARs. When HiperDispatch is used in the z/TPF system, the intention is to focus work to a minimal number of CPUs (or I-streams). By keeping the number of in-use I-streams on a z/TPF shared LPAR to a minimum, more resources are available to other shared LPARs and overall resource usage for the machine is more efficient.
Without HiperDispatch, the z/TPF system distributes work evenly across all I-streams in an LPAR. For example, if a shared LPAR has 10 I-streams and if 3200 milliseconds (or 3.2 seconds) of processing time is needed per second, all 10 I-streams have a utilization of about 32%.
When HiperDispatch is used and when the average utilization across all in-use I-streams reaches an expansion utilization value (80%), the z/TPF system expands the number of in-use I-streams by one. The number of I-streams can be expanded as high as the I-stream cap.
Consider the following example. A shared LPAR partition has 10 I-streams and 3200 milliseconds of CPU processing time is required. When the expansion utilization value is 80%, only 4 I-streams are used. Each I-stream has a utilization of about 80%. No application work is distributed to the remaining 6 I-streams. These remaining 6 logical I-streams have a utilization close to 0%.
In addition to expanding in-use I-streams, HiperDispatch provides support to automatically collapse the number of in-use I-streams. Extending the previous example, assume the work load decreases. Rather than 3200 milliseconds of CPU processing time per second, only 2100 milliseconds of CPU processing time per second is required. In this case, the z/TPF system collapses to 3 I-streams. Each Istream has a utilization of about 70%. No application work is distributed to the remaining 7 logical I-streams.
Designate utilities as low priority z/TPF work
A utility is work that does not follow the request response model of a transaction. Typically, a utility is started by the operator or it is started at a specific time (time initiated). In addition, a utility usually does more work than a transactional request.
Without dynamic CPU capacity, when a utility is started on the z/TPF system, it has equal priority to transactional work. To reduce the impact to transaction work, utilities are run during non-peak hours.
With dynamic CPU capacity, you can define all work for a specific utility as low priority. As the name suggests, low priority work processes only when there is no normal priority transactional work to process. The intention is to allow low priority work to run during peak periods during the day without affecting response time for transactional work.
During peak periods, the z/TPF LPAR is not usually running at 100% busy. Utilization might be 80% or 85% or 90% busy. If a z/TPF LPAR has 10 I-streams and the LPAR is running at 85% busy, there is 1500 milliseconds of unused processing time available every second. Low priority utilities can process during this unused time.
An API is provided to mark an ECB and its children ECBs as low priority. In addition, a prefix (-LP) is provided for system message processor (SMP) commands. When you use the -LP prefix, the API to mark the ECB and any children as low priority is automatically called before the specified command is processed.
For more information see APAR PJ44591.