z/os Performance: Capacity Planning Considerations for zaap Processors

Transcription

1 z/os Performance: Capacity Planning Considerations for zaap Processors White Paper November14, 2006 Version 1.6 Washington Systems Center Advanced Technical Support IBM Corporation, 2006 Capacity Planning Considerations for zaaps

2 Introduction: The new IBM ^ zseries Application Assist Processor (zaap) is an attractively priced specialized processing unit providing an economical Java execution environment for customers who desire the traditional Qualities of Service and the integration advantages of the zseries platform. When configured with general purpose processors within logical partitions running z/os, zaaps may help increase general purpose processor productivity and may contribute to lowering the overall cost of computing for z/os Java technology-based applications. zaaps are designed to operate asynchronously with the general purpose processors to execute Java programming under control of the IBM Java Virtual Machine (JVM). This can help reduce the demands and capacity requirements on general purpose processors which may then be available for reallocation to other zseries workloads. The IBM JVM processing cycles can be executed on the configured zaaps with no anticipated modifications to the Java application(s). Execution of the JVM processing cycles on a zaap is a function of the IBM Software Developer s Kit (SDK) for z/os, Java 2 Technology Edition, V1.4, z/os 1.6, and the Processor Resource/Systems Manager (PR/SM ). The amount of general purpose processor savings will vary based on the the amount of Java application code executed by zaap(s). This is dependent upon the amount of Java cycles used by the relevant application(s) and on the zaap execution mode selected by the customer. This paper is intended to provide several alternatives which installations can use to help estimate the potential workload able to exploit the zaap on their zseries CECs. The first portion of the paper contains the results of measurements by IBM with various Java based workloads. These results can be used to help estimate the ratios of Java to non-java processor consumption for select workload types. The next section of the paper will explain a technique which can be used for workloads currently in the development phase. These workloads are typically run for short periods of time to allow measurements to be made. The final section of the paper will explain a technique which can be used for workloads currently running in a production environment. These are workloads which run for extended periods of time, often in a 24 by 7 environment. Capacity Planning Considerations for zaaps Page 1

3 1.0 IBM Laboratory Measurements Some customers may want to consider the use of zaaps to support workloads which are not currently running on their processors. Since actual measurements are not possible for these workloads, an estimate can be obtained using a known workload to evaluate the ratio of time of Java work eligible to execute on a zaap versus general purpose processing. Using traditional sizing techniques for an application not currently running, the ratio can be applied to help estimate the number of CPs and zaaps needed to support the anticipated capacity requirement. In certain circumstances, the capacity of a configuration of CPs and zaaps is expected to be similar to a configuration where CPs are substituted for zaaps. For example, the capacity gained by adding a zaap to an existing configuration of three CPs can be similar to adding a CP to the same configuration. There is additional processing in the JVM and z/os to manage eligible Java work. Experience indicates this cost is variable and may depend on LPAR configuration and workload. When performing a high level sizing exercise, a 5% capacity addition for this activity is expected to be more than sufficient for most Java workloads. Note this consideration is for the eligible (Java) workloads only; it does not affect other workloads running in the same LPAR. In planning for zaaps, it is important to consider the service levels of the work eligible to use them. It may be typical to assume a utilization of 90% or higher in capacity planning. We have a term for this, the saturation design point ( SDP ). Utilizations of 90% often result in wait to using averages of 10 to 20, meaning the work will wait for the processor 10 to 20 times as long as its service time at the processor. This is often acceptable because there is work with a very relaxed response time objective to utilize the machine when the work with stringent response objectives has been satisfied. Our "loved ones" are not expected to experience those high delays. We have the designation of "discretionary" work in the WLM service definition to make clear the lack of a service level for some work. The zaap can only run Java work; therefore, one must consider the service levels of all eligible Java work and no other work when determining expected sustained utilization of zaaps. The Microsoft Excel workbook, zaap projection tool workbook, (reference Appendix B for more information) will remind you to consider this by using an SDP of 75% as a default, subject to your choice. IBM has measured several known workloads in order to estimate the ratio of Java execution time to the total system CPU time. The Java percent of total CPU time can vary for a given workload. It can be influenced by many factors which affect the Java execution time and/or the total system time. Some of these factors are processor configurations, software levels including z/os, WebSphere and the SDK, and system/subsystem tuning and customization parameters. The Java percent values should only be used as a reference. As your application is developed, actual measurements should be taken to establish a value for your specific implementation of the system. Capacity Planning Considerations for zaaps Page 2

4 Workload Name XML Parse Trade 2 Trade 3 CTG/CICS ERWW IMS Connect ERWW OLTP-T Java Percent of Total CPU time 98% 40% 60% 40% 40% 0% Description of Workload A CPU-intensive XML parsing workload which repeatedly parses XML documents using either SAX or DOM APIs both with and without validity checking. IBM developed workload modeling an electronic brokerage providing online securities trading. Provides a real-world ebusiness application mix of HTTP sessions, Servlets, JSPs, stateless session EJBs, container-managed persistent EJBs (CMPs) and JDBC data access to DB2. Generated with VA Java tooling, and characterized as light SQL with a small data base component. Third generation of WebSphere end-to-end benchmark evolved from Trade 2 and covering J2EE 1.3 including the EJB 2.0 component architecture, Message Driven beans with PUB/SUB and point-to-point asynchronous messaging. Characterized as light SQL with a small data base component. Web-Enabled access to a traditional CICS/DB2 OLTP database environment. J2EE application for legacy CICS transactions using servlets, JSPs, stateless session EJBs and the CICS Transaction Gateway (CTG). The size of the messages being passed between Websphere and CICS is relatively small. All the business logic is in the legacy CICS transactions and not in Java. Web-Enabled access to a traditional IMS/DB2 OLTP data base environment. J2EE application for legacy IMS transactions using servlets, JSPs, stateless session EJBs and IMS Connect. The size of the messages being passed between Websphere and IMS is relatively small. All the business logic is in the legacy IMS transactions and not in Java. Traditional IMS LSPR On-line Workload. Consists of light to moderate IMS transactions from DLI applications and using SNA LU2 message streams. Capacity Planning Considerations for zaaps Page 3

5 Sample Use of Data: A customer is planning to implement a new application using Web enabled CICS with CTG on a z990 processor. While MIPS tables may be useful for rough processor positioning, they should never be used for capacity planning purposes. Single-number processor capacity tables are inherently prone to error because they are not sensitive to the type of work being processed. The customer assumes a z990 CP delivers approximately 450 MIPS and realizes this value will have to be refined in the actual capacity plan, but this is a rough processor positioning exercise. The customer s application sizing effort has identified a requirement for 900 MIPS initially with 450 MIPS additional each quarter for the next 3 quarters. In this high level sizing exercise, the 5% additional capacity estimate for managing eligible Java work has been factored into these application requirements. The customer is asking what combination of hardware should be used to meet this requirement. Using the estimates from the IBM measurements for CTG/CICS ERWW would suggest the workload could use 40% * 900 = 360 MIPS of zaap and 540 MIPS of standard CP capacity. The following configuration is estimated to be able to support this application development process. Capacity Planning Considerations for zaaps Page 4

6 Time Period Initial +1Q +2Q +3Q General Purpose CP MIPS Required ,080 1,350 # General Purpose CPs zaap Assist Processors MIPS Eligible # of zaaps Comments There must be enough CPs to support the non zaap eligible work. Therefore, the CP will be required to handle the 540 MIPS with an additional 360 MIPS available. This available capacity can be used by the zaap eligible workload. The majority of the MIP requirement is general purpose based. The two CPs will support the 810 MIPS of general purpose work with 90 MIPS available. The one zaap will support approximately 450 MIPS of Java eligible work. The additional Java eligible work will be supported by the excess CP capacity. The three CPs will handle the 1080 MIPS of general purpose work with 270 MIPS of additional capacity. The one zaap will handle approximately 450 MIPS of Java eligible work. The additional Java eligible work will use the excess CP capacity The two zaaps will support approximately 900 MIPS of Java eligible work. The three CPs will support the 1350 MIPS of general purpose work. Note: For simplicity, N-way effects and target utilization are not included in this analysis example. You must include these factors in your analysis. Capacity Planning Considerations for zaaps Page 5

7 2.0 A Planning Methodology for Applications in the Development Phase Customers who are developing Java based applications on zseries processors may want to estimate the potential savings associated with using zaaps. These customers may have prototype code or application code running on the zseries processor which can be measured to allow projections. The difference in this level of analysis versus the first methodology is these customers will want to understand the projected ratio of Java eligible to non Java CPU time while their application code is executing. In order to answer this type of question, one needs to make actual measurements on the customer s machine while the application is running. As such, the length of time for the measurement can be measured in minutes or hours. At a minimum, we would like to get 15 minutes of data after the application has stabilized. This means if the environment for the application has a start up phase, or if the application needs to ramp up its transaction rate, we would like this portion of the measurement completed before we do our analysis. Our objective in this analysis is to figure out what the Java to non Java ratio is when the customer application is running. The data which will be used for this analysis is available with an IBM tool called the zaap Projection Tool for Java 2 Technology Edition (the Tool ). The Tool can be used to measure the Java eligible time. Information about this tool is available in Appendix A of this paper. The Tool is designed to create a print line in the STDERR file every five minutes. This interval is not related to the RMF or SMF intervals. The time will be reported as Java time eligible to execute on the zaap. The remaining time is identified as standard CP time. In addition, the total CPU time for all TCBs, SRBs and enclaves is reported as address space time. The following is a sample of the format and contents of this print line. IFA Projection data for system id=<sysd > Starting at: 18:31:30 - Current address space CPU: sec. <SYSD > Interval at: 18:36:30 Switches To/From IFA: Java IFA: 99.3 sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > Interval at: 18:41:30 Switches To/From IFA: Java IFA: sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > Interval at: 18:46:30 Switches To/From IFA: Java IFA: sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > Interval at: 18:51:30 Switches To/From IFA: Java IFA: sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > TOTAL at: 18:51:30 Switches To/From IFA: Java IFA: 418 sec. Java Standard CPU 429 sec. Total address space CPU: 878 sec. Capacity Planning Considerations for zaaps Page 6

8 A Microsoft Excel workbook is available with associated programming which will process these print lines and store the needed information into a spreadsheet. Further information about this workbook is available in Appendix B of this paper. The workbook will help the capacity planning person to manipulate the data in a spreadsheet. The rest of the analysis in this section makes use of the print line output being processed in the workbook. The following is a sample of the contents of the spreadsheet after execution within the workbook. SMF name Instance or Group RMF interval start zaap CP Space %Time zaap eligible zaap% engine eligible Other Java% engine Appl% engine zaap% w/capt ratio ZAAPs w/wait Service Class newwork all LPARS 85% 75% SYSD test1 18:31: % 33% 34% 70% 39% 52% SYSD test1 18:36: % 35% 36% 73% 41% 55% SYSD test1 18:41: % 37% 38% 78% 44% 58% SYSD test1 18:46: % 34% 35% 72% 40% 54% This information can help address multiple questions. The following chart is an example of the information which can be used to help estimate What percent of time a Java application can make use of a zaap. Sample Java Application % of Consumed CPU Time 100% 80% 60% 40% 20% 0% CP Required Java Eligible 2 Minute Intervals Capacity Planning Considerations for zaaps Page 7

9 If the purpose of the measurement is to help estimate the amount of CPU time required to support the application at a given rate, and the transaction rate could be added to the spreadsheet using some user defined means, the following example illustrates a chart which could be used to extrapolate the information. Sample Java Application 200% % Utilization 150% 100% 50% CP Java Eligible 0% Transaction Rate 3.0 A Planning Methodology for Applications in a Production Environment Customers running Java applications in a production environment may want to understand the potential for exploiting zaaps. This section will discuss the issues which should be considered and explain a technique which can help answer these questions. The first challenge in understanding the potential for zaaps is knowing the amount of Java eligible work running in a partition as well as when the work executes. This requires analysis of a larger amount of data which is collected over a longer period of time. The input to this analysis can be the total CPU consumption for the partition during a production cycle as well as the CPU consumed which is eligible to be dispatched on a zaap. The RMF type 70 record can provide the total CPU time consumed in the partition. The zaap Projection Tool for Java 2 Technology Edition can be used to measure the Java eligible time (see Appendix A). The customer will have to determine the length of time data will need to be collected by RMF. It is expected a 24 hour interval will be the minimum amount of time for the analysis. A peak day or representative day should be chosen. The total CPU consumed by the partition can be determined by using the RMF Partition Report. An example of the report is listed below. This report has had columns removed to improve readability. Capacity Planning Considerations for zaaps Page 8

10 z/os V1R2 P A T I T I O N D A T A R E P O R T INTERVAL SYSTEM ID WRC1 RPT VERSION V1R2 RMF MVS PARTITION NAME WRC1 IMAGE CAPACITY 191 NUMBER OF CONFIGURED PARTITIONS 4 NUMBER OF PHYSICAL PROCESSORS 3 CP 3 ICF 0 WAIT COMPLETION NO DISPATCH INTERVAL DYNAMIC PARTITION DATA AVERAGE PROCESSOR UTILZATION PERCENTAGES MSU---- -CAPPING-- LOGICAL PROCESSORS -- PHYSICAL PROCESSORS -- NAME S WGT DEF ACT DEF WLM% EFFECTIVE TOTAL LPAR MGMT EFFECTIVE TOTAL WRC1 A NO WRC2 A NO WRC3 A NO WRC4 A NO *PHYSICAL* The total amount of CPU time consumed by the partition can be calculated using the following formula: Total CPU Seconds = %Physical Processor Effective * #CPs * Interval(in secs) Total CPU Seconds =.5387 * 3 * (59*60+59) = 5816 seconds The total Java eligible time can be estimated using the Tool. The Tool needs to be enabled for each address space which can potentially execute Java code. Since the Tool does not synchronize its data with the RMF data, a technique needs to be used to allow the data to be merged with the RMF data. The workbook provides a technique to summarize any interval of 5 minutes or longer. It will associate a 5 minute Tool interval with the appropriate RMF interval which contained the majority of the tool interval. Although the tool intervals will not be aligned with RMF intervals precisely, we are primarily looking for the percentage of the CPU time eligible to execute on a zaap. This technique can be used for the entire measurement period. If the entire period is 24 hours, it may be appropriate to use a 1 hour reporting interval from RMF. If the measurement period is less than 24 hours, a smaller reporting interval from RMF is probably more appropriate. The customer will need to identify which address spaces can execute Java code and enable the Tool in each of these address spaces. The output of the Tool from each address space will need to be input to the Microsoft Excel workbook to get the needed information into a spread sheet. The RMF data will also need to be added to the spreadsheet. Once this information has been Capacity Planning Considerations for zaaps Page 9

11 entered into the spreadsheet, the following charts can be built by the planner which will help answer questions about the capacity planning needs to support the production Java workload. Potential zaap Utilization Estimate % of a CP Hour zaap % APPL CP % APPL This chart is a hypothetical example of a 24 hour measurement on a 10 processor CEC. It shows approximately 90% of the CEC is currently being consumed. There is a fair amount of Java work which runs during first and second shift with minimal Java work running during third shift. It is very valuable to understand the amount of Java work which runs on the machine as well as when it runs. If an analysis was done using only first shift information, it would appear a 10 processor machine with 5 general purpose processors and 5 zaaps would be an optimal configuration. However, if you look at the same data in the following chart you get a different picture. Capacity Planning Considerations for zaaps Page 10

12 % of a CP Potential zaap Utilization Estimate Hour CP % APPL zaap % APPL This data shows there is a need for 8 general purpose CPs to handle the capacity requirements for the non Java workload during third shift If this work must run without delay, then 5 general purpose CPs would reduce it s throughput. If we assume we must have 8 general purpose CPs for third shift and the total amount of capacity needed for all shifts is 10 processors, it may be appropriate to configure this machine with 8 general purpose CPs and 2 zaaps. The 2 zaaps are available to process Java workload throughout the day. The CPs are available to support the normal z/os work as well as the Java workload which exceeds the capacity of the two zaaps. (This discussion assumes the installation will allow crossover of Java work on the CPs --- see Appendix C for further discussion.) This second chart can provide input to a capacity plan for future processing needs. If the additional workload will run during third shift and is a non Java workload, then additional CPs will be needed. If the additional workload is Java based and will run during first shift, then a zaap may be a viable alternative. It can provide additional Java capacity for first shift as well as help offload some of the Java work running on the CPs. This can help provide additional Java capacity during first shift, and the potential for CP capacity reduction by the Java work may provide additional non Java capacity during first shift. Once this type of analysis is completed, it should provide the information to help drive the normal capacity planning process. Capacity Planning Considerations for zaaps Page 11

13 Summary: The zaap has the potential to deliver high performance Java processing in a cost effective manner on the zseries CEC. This new feature may have a potential impact on the capacity planning process for these machines. This paper has provided techniques which can aid in this capacity planning. It is planned this paper will be updated as additional experience is developed with the zaap capacity planning process. If you have questions about this paper, please contact your IBM account team. Notices: Trademarks Java is a trademark of Sun Microsystems, Inc. Microsoft and Excel are trademarks of Microsoft Corporation z/architecture, RMF and IMS are trademarks of International Business Machines Corporation in the United States or other countries or both. zseries, z/os, WebSphere, CICS are registered trademarks of International Business Machines Corporation in the United States or other countries or both. Other company, product, and service names may be trademarks or service marks of others Special Notices: This publication is intended to help the customer incorporate the zaap into the capacity planning process for the zseries CEC. The information in this publication is not intended as the specification of any programming interfaces provided by z/os. See the publication section of the IBM programming announcement for the appropriate z/os release for more information about what publications are considered to be product documentation. Where possible it is recommended to follow-up with product related publications to understand the specific impact of the information documented in this publication. The information contained in this document has not been submitted to any formal IBM test and is distributed on as as is basis without any warranty either expressed or implied. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their environment do so at their own risk. Performance data contained in this document was determined in a controlled environment with no other processing occurring and do not represent actual field measurement; therefore, the results which may be obtained in other operating environments may vary significantly. No Capacity Planning Considerations for zaaps Page 12

14 commitment as to your ability to obtain comparable results is in any way intended or made by this release of information. Capacity Planning Considerations for zaaps Page 13

15 Appendix A: The zaap Projection Tool for Java 2 Technology Edition Note: the SDK1.3.1 product at PTF level UQ94379 (SR24) or later now contains the projection function. That level can be obtained at The information on processor time is provided as messages in the STDERR file for each JVM. Interval information is intended to be written every 5 minutes, as well as beginning statistics and total values at termination. Each output file is intended to contain the data for only that job/address space or each JVM depending on scenario. An example of the output messages is the following: IFA Projection data for system id=<sysd > Starting at: 18:31:30 - Current address space CPU: sec. <SYSD > Interval at: 18:36:30 Switches To/From IFA: Java IFA: 99.3 sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > Interval at: 18:41:30 Switches To/From IFA: Java IFA: sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > Interval at: 18:46:30 Switches To/From IFA: Java IFA: sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > Interval at: 18:51:30 Switches To/From IFA: Java IFA: sec. Java Standard CPU sec. Interval address space CPU: sec. <SYSD > TOTAL at: 18:51:30 Switches To/From IFA: Java IFA: 418 sec. Java Standard CPU 429 sec. Total address space CPU: 878 sec. The key fields of interest for performance analysis are the following: Switches To/From IFA Java IFA Java Standard CPU State changes in processing of zaap eligible work versus not eligible work for all Java threads in the JVM Time accumulated for Java threads processing zaap eligible work. Please note it is possible for the JAVA IFA time to exceed the interval address space CPU time. This is due to the fact the JAVA IFA time is accumulated each time the task switches back to being eligible to run on the general purpose CPs. The interval address space CPU time is accumulated at the conclusion of each interval. If there is a long running Java thread which does not switch back to run on a general purpose CP during an interval, it s Java IFA time will not be recorded in that interval. Thus the Java IFA time reported could have been consumed in a previous interval. This will often show up for threads which do not terminate until the JVM ends. In this case, all of their Java IFA time can show up in the last recorded interval and the value will often be larger then the interval address space CPU Time for the last interval. Time accumulated for Java threads processing zaap Capacity Planning Considerations for zaaps Page 14

16 Interval address space CPU non-eligible work Time for all work in the address space across all dispatchable units including the Java threads IBM SDK for z/os Java 2 Technology Edition, Version 1.4 The measurement function of the tool as well as the total zaap support is planned to be part of the IBM SDK for z/os, Java 2 Technology Edition, V1.4, program product 5655-I56 with the PTF (or later) for APAR PQ New run-time options for this capability at this product version are planned to be added with the -Xifa options. Command line options that start with -X refer to nonstandard Java interpreter options and are anticipated to be unique to IBM and/or z/os. The options designed to control the new zaap support are the following: -Xifa:on Can enable Java work to be run on the zaap if the zaaps are available. It is designed so only code written in Java and Java system native code is enabled to run on a zaap. This design point is achieved in the Java support by requesting a switch to a zaap for qualifying work and a switch request from a zaap to a general purpose processor when nonqualifying work is encountered. This setting is assumed by default. -Xifa:off Designed to disable use of zaap. -Xifa:projectn Designed to estimate projected zaap usage and write this information to STDERR at intervals of n minutes. A value of 0 indicates information should only be written when Java terminates. Note: the interval requested is not honored exactly. Messages are written after a switch has been encountered for work considered eligible for offload or returning from that state. As a result, messages may be delayed during idle periods. This option is honored on all versions of z/os but is primarily intended for assessing potential zaap use on versions before z/os 1.6. z/os 1.6 has function to include zaap capacity planning information in SMF/RMF records. -Xifa:force Designed to force Java to continue attempting to use zaap, even if none are available. This would typically be specified for the purpose of collecting RMF/SMF data to assess potential zaap use. This option is honored only with the zaap support delivered with z/os 1.6. These options may be combined with the use of this Java product. The output produced with this product version is expected to be similar to the Tool output described in the previous section. Capacity Planning Considerations for zaaps Page 15

17 Java5 JVM on z/os The Java5 JVM implementation on z/os does not support the -Xifa:projectn option. Since the Java5 JVM requires z/os 1.6 or higher, there are two options for obtaining zaap usage estimations, both use the RMF Monitor I Workload Activity Report. Option 1: The Java5 JVM continues to support the -Xifa:force option. The downside to this approach is it requires updating the JVM arguments for all copies of the JVM and subsequently removing the option when finished. Option 2: The FMID which enables System z Integrated Information Processors (ziips) also brings new functionality to allow you to estimate zaap usage without setting any additional JVM arguments. This functionality is provided by FMID JBB77S9 (z/os 1.6) and JBB772S (z/os 1.7). Further information is available at: The zaap and ziip estimation information can be obtained from the RMF Workload Activity Report by setting the following option in the IEAOPTxx member of SYS1.PARMLIB: PROJECTCPU=YES The following excerpt is from an RMF Workload Activity Report generated using either option 1 or option 2 above. REPORT BY: POLICY=WLMPOL REPORT CLASS=RPXENCL HOMOGENEOUS: GOAL DERIVED FROM SERVICE CLASS T3ENC TRANSACTIONS TRANS-TIME HHH.MM.SS.TTT ---SERVICE---- SERVICE TIMES ---APPL %--- AVG 0.30 ACTUAL 3 IOC 0 CPU 24.4 CP MPL 0.30 EXECUTION 2 CPU SRB 0.0 AAPCP ENDED QUEUED 0 MSO 0 RCT 0.0 IIPCP 0.00 END/S R/S AFFIN SRB 0 IIT 0.0 #SWAPS 0 INELIGIBLE 0 TOT HST 0.0 AAP 0.00 EXCTD 0 CONVERSION 0 /SEC 4844 AAP 0.0 IIP 0.00 AVG ENC 0.30 STD DEV 11 IIP 0.0 REM ENC 0.00 ABSRPTN 16K MS ENC 0.00 TRX SERV 16K Using this new functionality in conjunction with existing reporting capability can allow you to estimate the zaap usage for each WLM service class. In this particular example, the enclaves running in this report class consumed 20.32% of an engine in the reported period, 17.11% of an engine is zaap eligible ( 84% of the enclave activity in this period is zaap eligible). Capacity Planning Considerations for zaaps Page 16

18 You can also easily estimate the total zaap usage across all service classes in a z/os image by using the following RMF report options in conjunction with PROJECTCPU=YES: SYSRPTS(WLMGL(SYSNAM(<system_name>))) SYSRPTS(WLMGL(POLICY)) This will yield a single Workload Activity Report for the period, consolidating all work in the designated system and allow you to easily estimate the zaap and/or ziip workload across all service classes on the z/os image. Capacity Planning Considerations for zaaps Page 17

19 Appendix B: The Microsoft Excel Workbook A spreadsheet summarization tool is available to assist in the analysis of the zaap Projection Tool Output. This Microsoft Excel workbook, zaap projection tool workbook.xls, can read the WebSphere SYSOUT file or Java output file containing the zaap projection tool messages. One needs to ftp the Java log files from z/os or obtain the files for processing under Excel by some other means. Since Websphere uses several address spaces, each of which will produce a Java log, an Excel workbook is a good means to organize the data and to do analysis such as combining projection data sheets from multiple address spaces. The zaap Projection Tool workbook can be downloaded from the same website as the zaap Projection Tool. This site is www6.software.ibm.com/dl/zosjava2/zosjava2-p This workbook is provided on an as is basis. An example of the data produced in the spreadsheet shows the following: SMF name Instance or Group RMF interval start zaap CP Space %Time zaap eligible zaap% engine eligible Other Java% engine Appl% engine zaap% w/capt ratio ZAAPs w/wait Service Class newwork all LPARS 85% 75% SYSD test1 18:31: % 33% 34% 70% 39% 52% SYSD test1 18:36: % 35% 36% 73% 41% 55% SYSD test1 18:41: % 37% 38% 78% 44% 58% SYSD test1 18:46: % 34% 35% 72% 40% 54% The zaap Projection Tool workbook is designed to provide the following capabilities: Capability to combine data from multiple JVMs Seconds of zaap eligible processing, non zaap-eligible (standard CP) processing, and total address space time for the Java space(s). Combines data from multiple address spaces, service classes and LPARs Combines the data and aligns to intervals such as the RMF interval used. Ability to adjust zaap utilization factoring in z/os capture ratios zaap and standard CP time expressed as a percent of the engine (single CP) the data was collected on. This can be used as input to the projected number of zaaps needed factoring in a target maximum utilization to ensure workload responsiveness. Capacity Planning Considerations for zaaps Page 18

20 Workbook Column Appl% engine zaap% w/capt ratio zaaps w/wait Description This column is the % of a CP being used by the address space during the interval. This column is the % of a zaap engine which could be used with the capture ratio applied. Since CPU time is captured time, it does not include the MVS uncaptured time. Normally a customer will calculate a capture ratio ( the difference between the total time used on a machine versus the captured time (TCB+SRB time)) and apply it to the captured time to estimate the total amount of time an address spaced used. This column is included if the customer wants to use it. The workbook allows you to update the capture ratio which is set to 90% by default. The capture ratio is specified in cell M2 It is really the SDP (saturation design point) value which is discussed in the workbook documentation. The concept of the SDP is to set an upper value of how busy you want a zaap to get. For example. If you want to make sure the zaap never gets more than 80% busy, you would set cell N2 to 80%. The actual % busy of the zaap is divided by this value. If the resulting cell is 100% it says you have consumed as much of the zaap as you wish. Some people feel, because the zaap may only process high priority work, you might not want to limit it's utilization. This column could be used to see how close you are to this value. Capacity Planning Considerations for zaaps Page 19

21 Appendix C: Additional Tuning and Planning Considerations APAR OA14131 is providing enhancements to the z/os dispatcher to help make better use of the zaap processor. Please review WSC Flash (z/os: Dispatcher Enhancements for zaaps) for further details on the use of these tuning options once this APAR is installed. z/os 1.6 is designed to provide options to control how zaap eligible work can be switched between standard processors and zaaps. Two new parameters can be defined in the IEAOPTxx member of SYS1.PARMLIB. IFACrossOver=Yes No IFAHonorPriority=Yes No Yes specifies zaap-eligible work may execute on both standard processors and zaaps. No specifies standard processors may not run any zaap eligible work unless there are no zaaps operational in the partition. Yes WLM will manage the priority of zaap eligible work for standard processors. Initially WLM will execute both zaap and non-zaap eligible work in priority order for standard CPs. The exception is when the customer is using software pricing with SCRT with a WLM managed cap on capacity. When the cap is limiting capacity, WLM will not allow standard CPs to process zaap eligible work. No specifies zaap eligible work can run on standard processors but at a priority lower than any non-zaap work IFAHonorPriority will only be taken into account when you specify IFACrossover=Yes. In order to decide the appropriate settings it is best to decide what you want to achieve with the installation of a zaap. Most customers ultimately fall into one of the three categories below: 1. Reduce software cost to the maximum by running all Java eligible work on the zaap. This may have an impact on performance. 2. Reduce software cost as much as possible, but allow Java work to use excess general purpose CP capacity if needed. 3. Continue to provide optimum performance for Java workloads while reducing software cost if possible. Capacity Planning Considerations for zaaps Page 20

22 As these parameters will influence the dispatching of work on the standard CPs, they will affect your capacity requirements for the standard CPs and zaaps. Allowing crossover will permit Java work to compete for standard CP resources in addition to executing on zaaps. The amount of Java crossover onto the standard CPs will be affected by the HonorPriority setting. If HonorPriority is desired, then Java work can be dispatched ahead of any lower priority non Java work. If HonorPriority is not desired with crossover, then the Java work can only use available CP capacity if there is no non Java work waiting to execute. Preventing crossover will relegate the Java work to the zaaps and may help simplify the tracking of this work. If standard CP capacity becomes a bottleneck, this resource is expected to be restricted for non Java work and force the Java work to execute only on zaaps. This may be appropriate if there is ample planned zaap capacity or the preference is to fully utilize the cheaper zaap resource. The utilization of the zaaps may match up closer to the capacity planning projections generated with the measurement tooling and spreadsheet analysis described in the earlier sections of this paper. However, preventing crossover can eliminate the flexibility to use standard CP cycles if standard CP resource is available and can prevent the execution of additional Java work if the zaap resources are fully utilized. In addition to the capacity planning considerations, the CPU utilization of the standard CPs will change and will affect the IBM software charges for VWLC products with SCRT. If the objective for the zaap is to reduce software cost to the maximum ( option #1 ) you should consider using IFACrossOver = NO. All eligible Java work will run on the zaap. There is the potential for eligible Java work to wait to gain access to the zaap CP when general purpose CP capacity is available. If the objective for the zaap is to maximize performance of Java workload and reduce software cost if possible ( option # 3 ), you should consider using IFACrossOver = YES and IFAHonorPriority = YES. This will allow the general purpose CPs to select the highest priority ready work regardless of workload type. If the objective for the zaap is to reduce software cost as much as possible while maintaining performance ( option # 2), you should consider using IFACrossOver = YES and IFAHonorPriority = NO. This will allow the general purpose CPs to select Java work only if there is no other work ready to run. Thus, as long as any CP is available, the Java work will be dispatched. Capacity Planning Considerations for zaaps Page 21

23 Appendix D: LPAR Weight Management Considerations Physical CPs can be dedicated to a single partition or shared by multiple partitions. The amount of CPU resource guaranteed to a shared partition is defined by the weight specification. The following formulae is used to determine the amount of resource guaranteed: % CPU Resource = Partition Weight ( within this processor pool ) Total Weight ( of this processor pool ) The following example may prove helpful: This example assumes the processor has 10 general purpose CPs which are all being shared. This means they are all in the same processor pool ( general purpose CP pool ) Partition Name ZOS1 ZOS2 ZOS3 TOTAL Weight ,000 % CPU Resource (500/1000) = 50 (200/1000) = 20 (300/1000) = 30 Equivalent CP Capacity 50% * 10 = 5 20% * 10 = 2 30% * 10 = 3 Now lets add a dedicated ICF and an IFL which will be shared by two partitions running Linux. The ICF and IFL CPs are managed in a different pool ( ICF pool ) than the general purpose CPs. Partition Name ZOS1 ZOS2 ZOS3 TOTAL ICF1 LINUX1 LINUX2 TOTAL Weight ,000 Dedicated % CPU Resource (500/1000) = 50 (200/1000) = 20 (300/1000) = 30 (50/100) = 50 (50/100) = 50 Equivalent CP Capacity 50% * 10 = 5 20% * 10 = 2 30% * 10 = % * 1 =.5 50% * 1 =.5 Capacity Planning Considerations for zaaps Page 22

24 Now lets add a zaap to be shared by partitions ZOS2 and ZOS3. The zaap CP is managed out of the ICF pool but inherits the weight specified for the general purpose CPs of the partitions it is supporting. The above sentence is true for the z990 and z890. The zaap CP is managed out of its own pool on the System z9. As such, the need to manipulate the weights discussed below is not needed on a System z9 processor. If there are no adjustments to weights notice the amount of CP resource and % CPU Resource available to each partition in the ICF pool. Partition Name ZOS1 ZOS2 ZOS3 TOTAL ICF1 LINUX1 LINUX2 ZOS2 ZOS3 TOTAL Weight ,000 Dedicated % CPU Resource (500/1000) = 50 (200/1000) = 20 (300/1000) = 30 (50/600) = 08 (50/600) = 08 (200/600) = 33 (300/600) = 50 Equivalent CP Capacity 50% * 10 = 5 20% * 10 = 2 30% * 10 = 3 1 8% * 2 = % * % * 2 = % * 2 = 1 You see the Linux partitions have lost capacity with the addition of the zaap processor. This is due to the fact the zaap weights are not specified in the HMC definitions but are inherited from the HMC definitions for the general purpose CPs. This obviously is not what we want. In order to guarantee the Linux partitions the same amount of CP resource we need to adjust the weights for the ICF shared pool. Since we can not change the weights for the zaap CPs, we MUST change the weight for the other CPs. Capacity Planning Considerations for zaaps Page 23

25 Since we added 1 zaap CP to the pool and added a combined zaap weight of 500, then a single CP in the ICF pool must equate to a weight of 500. Once we know this value, we can recalculate the weight for the other ICF pool shared CP Partitions. The following formulae is used to determine the new partition weights: Partition Weight = Equivalent CP Capacity ( For the Partition) * Weight of a Single CP ( For the ICF Pool) Lets use this formulae to update the LPAR weight definitions Partition Name ZOS1 ZOS2 ZOS3 TOTAL ICF1 LINUX1 LINUX2 ZOS2 ZOS3 TOTAL Weight ,000 Dedicated ,000 % CPU Resource (500/1000) = 50 (200/1000) = 20 (300/1000) = 30 (250/1000) = 25 (250/1000) = 25 (200/1000) = 20 (300/1000) = 30 Equivalent CP Capacity 50% * 10 = 5 20% * 10 = 2 30% * 10 = % * 2 =.5 25% * 2 =.5 20% * 2 = % * 2 = 0.6 These new LPAR weights now guarantee the Linux partitions the same amount of CP resource as they had prior to adding the zaap CP and the zos partitions are guaranteed the amount of the zaap CP as defined by the zos2 and zos3 weights. This exercise is only needed if the CPs in the ICF pool are being shared and are servicing more than one type of workload ( ICF, IFL or zaap ). If all the ICF pool CPs are dedicated this calculation is not needed. Capacity Planning Considerations for zaaps Page 24