|
|
|
Prior to the zAAP, CPU capacity tracking and planning for z/OS dealt with only one processor type, the standard CP (or general purpose) processor. With the introduction of the zAAP and zIIP specialized processors, three types of processors are used by z/OS, and separate sets of measurements must be used to analyze LPAR utilization. Three simple examples illustrate that traditional capacity methods must be updated as soon as you include specialized processors in your pool of CPU resources, in order to answer the same questions always asked: How effectively are my CPU resources used? Do I need more and which type? Example 1 --------- Logical partition ZOS1 is configured with two standard CP processors and one specialized processor. Last month, the average utilization of each of these processors was: CP Processor 1: 80% CP Processor 2: 80% Special Proc. : 20% Using the traditional method, the average utilization of the ZOS1 LPAR for the month would appear to be 60% (180%/3). Does this information provide the answers to the previous questions? Obviously not, since all the processors are reported together, hiding the relatively important load of the standard CPs compared to the low utilization of the specialized processor. We cannot make any decision based on such an overall perspective. Now, using an updated method, we end up with two utilization percentages, showing that the standard CPs were busy 80% of the time, and the specialized processor only 20%. This is much more valuable in regards to the important questions: o How effectively are my CPU resources used? This LPAR is correctly sized in terms of standard CP processors. 80% busy means it really needs its two standard CPs to handle the classical z/OS workload. On the other hand the specialized processor is only used 20% of the time. We can maximize its utilization either by moving the eligible workload from other LPARs into ZOS1; or even by removing the specialized processor from ZOS1 (the standard CPs might support the workload previously only executed on this processor) and assigning it to another LPAR. (This assumes the specialized processor is executing at the same speed as the standard CP processors, since the RMF records the CPU times at the physical engine speed.) o Do I need more CPU resources and which type? With this current configuration, you know you can handle an 80% increase in special workload, but only 20% in other z/OS processing. Note that the 20% may be further reduced if your data center allows special work to be executed on both standard and specialized processors. Example 2 --------- Logical partition ZOS2 is configured with two standard CP processors and one specialized processor. Last month, the average utilization of each of these processors was: CP Processor 1: 30% CP Processor 2: 30% Special Proc. : 100% Using the traditional method, the average utilization of the ZOS2 LPAR for the month would appear to be 53% (160%/3). Does this information provide the answers to the previous questions? Here, again, we cannot make any decision based on such combined information. Now, using an updated method, we end up with two utilization percentages, showing that the standard CPs were busy 30% of the time, and the specialized processor 100%. A lot more useful information would be as follows: o How effectively are my CPU resources used? This time, the LPAR is underutilizing its standard CP processors because 30% busy means only one standard CP would be sufficient to handle all classical z/OS workload. On the other hand, the specialized processor is 100% busy. We could not make any better profit of this low-cost assistant. o Do I need more CPU resources and which type? In this configuration, the specialized processor cannot accept any additional workload, but the standard CP processors could support a 70% increase before reaching their full capacity. Since, depending on the system parameters, this extra capacity could be used by both special and classical z/OS workload, a trade-off has to be found between spending standard CP processor CPU cycles for special work (and thus increasing the MSU consumption of the LPAR), or adding a new low-cost specialized processor. Performance is also a factor when a specialized processor is too heavily loaded because special work may be queued waiting for it while standard CPs are available. Example 3 --------- The two previous examples were intended to show you how reporting solely at the overall LPAR level could be misleading, but in a real configuration, you may have to deal with LPARs where both types of processors are loaded in a comparable way. This last example shows that the information CA MICS obtains from PR/SM is not sufficient to have a full understanding of such LPARs' utilization, and that a complete analysis requires gathering additional measurements from WLM at the workload level. Logical partition ZOS3 is configured with two standard CP processors and one specialized processor. Last month, the average utilization of each of these processors was: CP Processor 1: 90% CP Processor 2: 90% Special Proc. : 90% Using the traditional method, the average utilization of the ZOS3 LPAR for the month would appear to be 90% (270%/3). This time, at least, this percentage tells us that there is not much room left for additional workload. But, again it does not answer the main capacity planning questions. Let's assume the specialized processor is a zAAP. Not surprisingly, using the updated method, we end up with two similar utilization percentages, showing that both the standard CPs and zAAP were busy 90% of the time. But, if we know the zAAP can only be busy with Java work, we must determine what is actually making the standard CPs so busy too. If the data center does not allow any Java work to run on standard CPs, there is no doubt: these processors are busy with non-Java work only, and as such, there is no way to dispatch part of their workload to a zAAP, in order to reduce their utilization. Therefore they may only support a 10% load increase. Things become more complex if Java work is allowed to execute both on zAAP and standard CPs. Java work running on a standard CP is called "zAAP eligible," and the CPU time consumed by this type of work is not recorded separately in the SMF type 70 subtype 1 record. RMF gathers this information from the Workload Manager (WLM), and you must retrieve it from the WLMSEC, Service Class Resource Consumption file. Suppose you determined that half of the CPU time consumed on the standard CPs was attributable to zAAP eligible time. This means that your 90% busy for the standard CPs is now distributed as follows: CP Processors Busy: 90% Java Workload : 45% non-Java Workload : 45% With this information, it is now possible to evaluate the potential solutions: for example, install a new zAAP; then force Java work to run on zAAPs only; and finally, since the standard CPs utilization has decreased to 45%, remove one of them and reduce the LPAR MSU capacity. Below is a matrix of basic data elements you can use as a starting point for dual standard CP and specialized processor utilization analysis:
+----------+------------------------------------------------+ ! File: ! HARCPU - CPU Activity File ! ! ! ! +==========+================================================+ ! Element ! Label ! +----------+------------------------------------------------+ ! CPUAVONL ! Avg Number of Online CP Processors ! ! CPUAVOZP ! Avg Number of Online zAAP Processors ! ! CPUAVOSU ! Avg Number of Online zIIP Processors ! +----------+------------------------------------------------+ ! CPUPCBSY ! Pct CP Processors Busy ! ! CPUPCBZP ! Pct zAAP Processors Busy ! ! CPUPCBSU ! Pct zIIP Processors Busy ! +----------+------------------------------------------------+ ! CPUPCTDT ! Pct CP Proc. Dispatched - Effective ! ! CPUPCTDZ ! Pct zAAP Proc. Dispatched - Effective ! ! CPUPCTDS ! Pct zIIP Proc. Dispatched - Effective ! +----------+------------------------------------------------+ ! CPUTOBTM ! Total Time CP Processors Busy !! CPUZPBTM ! Total Time zAAP Processors Busy ! ! CPUSUBTM ! Total Time zIIP Processors Busy +----------+------------------------------------------------+ ! CPUTODTM ! Total CP Processors Dispatch Time ! ! CPUZPDTM ! Total zAAP Processors Dispatch Time ! ! CPUSUDTM ! Total zIIP Processors Dispatch Time ! +----------+------------------------------------------------+ ! CPUTOOTM ! Total CP Processors Online Time ! ! CPUZPOTM ! Total zAAP Processors Online Time ! ! CPUSUOTM ! Total zIIP Processors Online Time ! +----------+------------------------------------------------+ +----------+------------------------------------------------+ ! File: ! HARLPC - PR/SM LPAR Config/Activity File ! ! ! !
+==========+================================================+ ! Element ! Label ! +----------+------------------------------------------------+ ! LPCAVCPU ! Avg Number of Active CP Processors ! ! LPCAVICF ! Avg Number of Active ICF Processors (zSeries) ! ! LPCAVZAP ! Avg Number of Active zAAP Processors (z9) ! ! LPCAVSUP ! Avg Number of Active zIIP Processors (z9) ! +----------+------------------------------------------------+ ! LPCPCSSU ! LPAR Shared CP Processors Utilization ! ! LPCPCSIU ! LPAR Shared ICF Procs. Utilization (zSeries) ! ! LPCPCSZU ! LPAR Shared zAAP Procs. Utilization (z9) ! ! LPCPCSDU ! LPAR Shared zIIP Procs. Utilization (z9) ! +----------+------------------------------------------------+ ! LPCPCTSU ! LPAR Total CP Processors Utilization ! ! LPCPCTIU ! LPAR Total ICF Processors Utilization (zSeries)! ! LPCPCTZU ! LPAR Total zAAP Processors Utilization (z9) ! ! LPCPCTDU ! LPAR Total zIIP Processors Utilization (z9) ! +----------+------------------------------------------------+ ! LPCPCVPU ! LPAR CP Processors Utilization ! ! LPCPCVIU ! LPAR ICF Processors Utilization (zSeries) ! ! LPCPCVZU ! LPAR zAAP Processors Utilization (z9) ! ! LPCPCVSU ! LPAR zIIP Processors Utilization (z9) ! +----------+------------------------------------------------+ ! LPCTODTM ! Total CP Processors Dispatch Time ! ! LPCTIDTM ! Total ICF Processors Dispatch Time (zSeries) ! ! LPCTZDTM ! Total zAAP Processors Dispatch Time (z9) ! ! LPCTSDTM ! Total zIIP Processors Dispatch Time (z9) ! +----------+------------------------------------------------+ ! LPCTOEDT ! Total CP Proc. Effective Dispatch Time ! ! LPCTIEDT ! Total ICF Proc. Effective Dispatch Tm (zSeries)! LPCTZEDT ! Total zAAP Proc. Effective Dispatch Time (z9) ! ! LPCTSEDT ! Total zIIP Proc. Effective Dispatch Time (z9) ! +----------+------------------------------------------------+ ! LPCTOOTM ! Total CP Processors Online Time ! ! LPCTIOTM ! Total ICF Processors Online Time (zSeries) ! ! LPCTZOTM ! Total zAAP Processors Online Time (z9) ! ! LPCTSOTM ! Total zIIP Processors Online Time (z9) ! +----------+------------------------------------------------+ +----------+------------------------------------------------+ ! File: !WLMSEC - Service Class Resource Consumption + ! ! ! +==========+================================================+ ! Element ! Label ! +----------+------------------------------------------------+ ! WLMZAPNF ! zAAP Service Time Normalization Factor ! ! WLMSUPNF ! zIIP Service Time Normalization Factor ! +----------+------------------------------------------------+ ! SECCPUTM ! CPU Time on CP ! ! SECZAPTM ! CPU Time on zAAP (Normalized) ! ! SECSUPTM ! CPU Time on zIIP (Normalized) ! ! SECZAPCT ! zAAP Eligible CPU Time on CP ! ! SECSUPCT ! zIIP Eligible CPU Time on CP ! ! SECZAPUT ! Un-normalized zAAP CPU Time ! ! SECSUPUT ! Un-normalized zIIP CPU Time ! +----------+------------------------------------------------+ ! SECTOCPU ! CPU Service Units on CP ! ! SECTOZAP ! CPU Service Units on zAAP ! ! SECTOSUP ! CPU Service Units on zIIP ! ! SECTZAPC ! zAAP Eligible CPU Service Units on CP ! ! SECTSUPC ! zIIP Eligible CPU Service Units on CP ! +----------+------------------------------------------------+ +----------+------------------------------------------------+ ! File: ! WLMSDE - Service Definition ! ! ! ! +==========+================================================+ ! Element ! Label ! ----------+------------------------------------------------+ ! SDEIFAHO ! Intvls with IFAHonorPriority ! +----------+------------------------------------------------+ ! SDEIFAXO ! Intvls with IFACrossOver ! +----------+------------------------------------------------+
| Copyright © 2012 CA. All rights reserved. | Tell Technical Publications how we can improve this information |