z/os performance: capacity planning considerations for

��

z/OS Performance: Capacity PlanningConsiderations for zAAP Processors

White PaperNovember14, 2006

Version 1.6

Washington Systems CenterAdvanced Technical Support

© IBM Corporation, 2006

© 2005, IBM Advanced Technical Support Techdocs - Washington Systems Center 11/14/2006 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100417Capacity Planning Considerations for zAAPs

Introduction:

The new IBM ^® zSeries® Application Assist Processor (zAAP) is an attractively pricedspecialized processing unit providing an economical Java™ execution environment for customerswho desire the traditional Qualities of Service and the integration advantages of the zSeriesplatform.

When configured with general purpose processors within logical partitions running z/OS, zAAPsmay help increase general purpose processor productivity and may contribute to lowering theoverall cost of computing for z/OS Java technology-based applications. zAAPs are designed tooperate asynchronously with the general purpose processors to execute Java programming undercontrol of the IBM Java Virtual Machine (JVM). This can help reduce the demands and capacityrequirements on general purpose processors which may then be available for reallocation toother 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 afunction 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 Javaapplication code executed by zAAP(s). This is dependent upon the amount of Java cycles usedby 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 helpestimate the potential workload able to exploit the zAAP on their zSeries CECs. The firstportion of the paper contains the results of measurements by IBM with various Java basedworkloads. These results can be used to help estimate the ratios of Java to non-Java processorconsumption for select workload types. The next section of the paper will explain a techniquewhich can be used for workloads currently in the development phase. These workloads aretypically run for short periods of time to allow measurements to be made. The final section ofthe paper will explain a technique which can be used for workloads currently running in aproduction environment. These are workloads which run for extended periods of time, often in a24 by 7 environment.

© 2005, IBM Advanced Technical Support Techdocs - Washington Systems Center 11/14/2006 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100417Capacity Planning Considerations for zAAPs Page 1

1.0 IBM Laboratory Measurements

Some customers may want to consider the use of zAAPs to support workloads which are notcurrently running on their processors. Since actual measurements are not possible for theseworkloads, an estimate can be obtained using a known workload to evaluate the ratio of time ofJava work eligible to execute on a zAAP versus general purpose processing. Using traditionalsizing techniques for an application not currently running, the ratio can be applied to helpestimate 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 capacitygained by adding a zAAP to an existing configuration of three CPs can be similar to adding aCP to the same configuration. There is additional processing in the JVM and z/OS to manageeligible Java work. Experience indicates this cost is variable and may depend on LPARconfiguration and workload. When performing a high level sizing exercise, a 5% capacityaddition for this activity is expected to be more than sufficient for most Java workloads. Notethis consideration is for the eligible (Java) workloads only; it does not affect other workloadsrunning in the same LPAR.

In planning for zAAPs, it is important to consider the service levels of the work eligible to usethem. It may be typical to assume a utilization of 90% or higher in capacity planning. We havea term for this, the saturation design point ( SDP ). Utilizations of 90% often result in wait tousing averages of 10 to 20, meaning the work will wait for the processor 10 to 20 times as longas its service time at the processor. This is often acceptable because there is work with a veryrelaxed response time objective to utilize the machine when the work with stringent responseobjectives 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 clearthe lack of a service level for some work. The zAAP can only run Java work; therefore, onemust consider the service levels of all eligible Java work and no other work when determiningexpected sustained utilization of zAAPs. The Microsoft Excel workbook, zAAP projection toolworkbook, (reference Appendix B for more information) will remind you to consider this byusing 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 timeto the total system CPU time. The Java percent of total CPU time can vary for a givenworkload. It can be influenced by many factors which affect the Java execution time and/or thetotal system time. Some of these factors are processor configurations, software levels includingz/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 thesystem.


Traditional IMS LSPR On-line Workload.Consists of light to moderate IMS transactionsfrom DLI applications and using SNA LU2message streams.

0%OLTP-T

Web-Enabled access to a traditional IMS/DB2OLTP data base environment. J2EE applicationfor legacy IMS transactions using servlets, JSPs,stateless session EJBs and IMS Connect. Thesize of the messages being passed betweenWebsphere and IMS is relatively small. All thebusiness logic is in the legacy IMS transactionsand not in Java.

40%IMS Connect ERWW

Web-Enabled access to a traditional CICS/DB2OLTP database environment. J2EE applicationfor legacy CICS transactions using servlets,JSPs, stateless session EJBs and the CICSTransaction Gateway (CTG). The size of themessages being passed between Websphere andCICS is relatively small. All the business logic isin the legacy CICS transactions and not in Java.

40%CTG/CICS ERWW

Third generation of WebSphere end-to-endbenchmark evolved from Trade 2 and coveringJ2EE 1.3 including the EJB 2.0 componentarchitecture, Message Driven beans withPUB/SUB and point-to-point asynchronousmessaging. Characterized as light SQL with asmall data base component.

60%Trade 3

IBM developed workload modeling an electronicbrokerage providing online securities trading.Provides a real-world eBusiness application mixof HTTP sessions, Servlets, JSPs, statelesssession EJBs, container-managed persistent EJBs(CMPs) and JDBC data access to DB2.Generated with VA Java tooling, andcharacterized as light SQL with a small data basecomponent.

40%Trade 2

A CPU-intensive XML parsing workload whichrepeatedly parses XML documents using eitherSAX or DOM APIs both with and withoutvalidity checking.

98%XML Parse

Description of WorkloadJava Percent ofTotal CPUtime

Workload Name


Sample Use of Data:

A customer is planning to implement a new application using Web enabled CICS with CTG on az990 processor. While MIPS tables may be useful for rough processor positioning, they shouldnever be used for capacity planning purposes. Single-number processor capacity tables areinherently 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 willhave 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 with450 MIPS additional each quarter for the next 3 quarters. In this high level sizing exercise, the5% additional capacity estimate for managing eligible Java work has been factored into theseapplication requirements. The customer is asking what combination of hardware should be usedto meet this requirement.

Using the estimates from the IBM measurements for CTG/CICS ERWW would suggest theworkload 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 developmentprocess.


The two zAAPs will supportapproximately 900 MIPS of Javaeligible work. The three CPs willsupport the 1350 MIPS of generalpurpose work.

290031,350+3Q

The three CPs will handle the 1080MIPS of general purpose work with270 MIPS of additional capacity.The one zAAP will handleapproximately 450 MIPS of Javaeligible work. The additional Javaeligible work will use the excess CPcapacity

172031,080+2Q

The majority of the MIP requirementis general purpose based. The twoCPs will support the 810 MIPS ofgeneral purpose work with 90 MIPSavailable. The one zAAP willsupport approximately 450 MIPS ofJava eligible work. The additionalJava eligible work will be supportedby the excess CP capacity.

15402810+1Q

There must be enough CPs to supportthe non zAAP eligible work.Therefore, the CP will be required tohandle the 540 MIPS with anadditional 360 MIPS available. Thisavailable capacity can be used by thezAAP eligible workload.

03602540Initial

Comments# of zAAPs

zAAPAssistProcessorsMIPSEligible

#GeneralPurposeCPs

GeneralPurposeCP MIPSRequired

TimePeriod

Note: For simplicity, N-way effects and target utilization are not included in this analysis example.You must include these factors in your analysis.


2.0 A Planning Methodology for Applications in the Development Phase

Customers who are developing Java based applications on zSeries processors may want toestimate the potential savings associated with using zAAPs. These customers may haveprototype code or application code running on the zSeries processor which can be measured toallow projections. The difference in this level of analysis versus the first methodology is thesecustomers will want to understand the projected ratio of Java eligible to non Java CPU timewhile their application code is executing.

In order to answer this type of question, one needs to make actual measurements on thecustomer’s machine while the application is running. As such, the length of time for themeasurement can be measured in minutes or hours. At a minimum, we would like to get 15minutes of data after the application has ‘stabilized’. This means if the environment for theapplication has a start up phase, or if the application needs to ‘ramp up’ its transaction rate, wewould like this portion of the measurement completed before we do our analysis. Our objectivein this analysis is to figure out what the Java to non Java ratio is when the customer applicationis running.

The data which will be used for this analysis is available with an IBM tool called the zAAPProjection Tool for Java 2 Technology Edition (the “Tool”). The Tool can be used to measurethe Java eligible time. Information about this tool is available in Appendix A of this paper. TheTool is designed to create a print line in the STDERR file every five minutes. This interval isnot related to the RMF or SMF intervals. The time will be reported as Java time eligible toexecute on the zAAP. The remaining time is identified as standard CP time. In addition, thetotal CPU time for all TCBs, SRBs and enclaves is reported as address space time. Thefollowing is a sample of the format and contents of this print line.


IFA Projection data for system id=<SYSD.50594238> Starting at: 18:31:30 - Currentaddress space CPU: 0.008068 sec.<SYSD.50594238> Interval at: 18:36:30 Switches To/From IFA: 3717251 Java IFA: 99.3sec. Java Standard CPU 101.86 sec. Interval address space CPU: 208.66 sec.<SYSD.50594238> Interval at: 18:41:30 Switches To/From IFA: 3903114 Java IFA: 104.27sec. Java Standard CPU 106.95 sec. Interval address space CPU: 219.09 sec.<SYSD.50594238> Interval at: 18:46:30 Switches To/From IFA: 4176332 Java IFA: 111.57sec. Java Standard CPU 114.44 sec. Interval address space CPU: 234.43 sec.<SYSD.50594238> Interval at: 18:51:30 Switches To/From IFA: 3842225 Java IFA: 102.64sec. Java Standard CPU 105.28 sec. Interval address space CPU: 215.68 sec.<SYSD.50594238> TOTAL at: 18:51:30 Switches To/From IFA: 15638922 Java IFA: 418sec. Java Standard CPU 429 sec. Total address space CPU: 878 sec.

A Microsoft Excel workbook is available with associated programming which will process theseprint lines and store the needed information into a spreadsheet. Further information about thisworkbook is available in Appendix B of this paper. The workbook will help the capacityplanning person to manipulate the data in a spreadsheet. The rest of the analysis in this sectionmakes use of the print line output being processed in the workbook. The following is a sampleof the contents of the spreadsheet after execution within the workbook.

This information can help address multiple questions. The following chart is an example of theinformation which can be used to help estimate ‘What percent of time a Java application canmake use of a zAAP’.


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:00 99 102 209 48% 33% 34% 70% 39% 52%SYSD test1 18:36:00 104 107 219 48% 35% 36% 73% 41% 55%SYSD test1 18:41:00 112 114 234 48% 37% 38% 78% 44% 58%SYSD test1 18:46:00 103 105 216 48% 34% 35% 72% 40% 54%

Sample Java Application

0%

20%

40%

60%

80%

100%

1 2 3

2 Minute Intervals

% o

f Con

sum

ed C

PUTi

me CP Required

Java Eligible

If the purpose of the measurement is to help estimate the amount of CPU time required tosupport the application at a given rate, and the transaction rate could be added to the spreadsheetusing some user defined means, the following example illustrates a chart which could be used toextrapolate the information.

3.0 A Planning Methodology for Applications in a Production Environment

Customers running Java applications in a production environment may want to understand thepotential for exploiting zAAPs. This section will discuss the issues which should be consideredand explain a technique which can help answer these questions.

The first challenge in understanding the potential for zAAPs is knowing the amount of Javaeligible work running in a partition as well as when the work executes. This requires analysis ofa larger amount of data which is collected over a longer period of time. The input to thisanalysis can be the total CPU consumption for the partition during a production cycle as well asthe CPU consumed which is eligible to be dispatched on a zAAP. The RMF type 70 record canprovide the total CPU time consumed in the partition. The zAAP Projection Tool for Java 2Technology 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. Itis expected a 24 hour interval will be the minimum amount of time for the analysis. A peak dayor representative day should be chosen. The total CPU consumed by the partition can bedetermined by using the RMF Partition Report. An example of the report is listed below. Thisreport has had columns removed to improve readability.


Sample Java Application

0%

50%

100%

150%

200%

45 65 85

Transaction Rate

% U

tiliz

atio

n

CPJava Eligible

The total amount of CPU time consumed by the partition can be calculated using the followingformula:

The total Java eligible time can be estimated using the Tool. The Tool needs to be enabled foreach address space which can potentially execute Java code. Since the Tool does notsynchronize its data with the RMF data, a technique needs to be used to allow the data to bemerged with the RMF data. The workbook provides a technique to summarize any interval of 5minutes or longer. It will associate a 5 minute Tool interval with the appropriate RMF intervalwhich contained the majority of the tool interval. Although the tool intervals will not be alignedwith RMF intervals precisely, we are primarily looking for the percentage of the CPU timeeligible to execute on a zAAP.

This technique can be used for the entire measurement period. If the entire period is 24 hours, itmay be appropriate to use a 1 hour reporting interval from RMF. If the measurement period isless 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 theTool in each of these address spaces. The output of the Tool from each address space will needto 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


P A T I T I O N D A T A R E P O R T INTERVAL 000.59.59 z/OS V1R2 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 TOTALWRC1 A 530 0 103 NO 0.0 80.80 81.00 0.13 53.87 54.00WRC2 A 300 0 51 NO 0.0 40.03 40.27 0.16 26.69 26.85 WRC3 A 120 0 14 NO 0.0 10.99 11.19 0.14 7.32 7.46WRC4 A 10 0 0 NO 0.0 0.00 0.00 0.00 0.00 0.00*PHYSICAL* 0.90 0.90 ---- ----- ----- 1.33 87.88 89.21

Total CPU Seconds = %Physical Processor Effective * #CPs * Interval(in secs)

Total CPU Seconds = .5387 * 3 * (59*60+59) = 5816 seconds

entered into the spreadsheet, the following charts can be built by the planner which will helpanswer questions about the capacity planning needs to support the production Java workload.

This chart is a hypothetical example of a 24 hour measurement on a 10 processor CEC. It showsapproximately 90% of the CEC is currently being consumed. There is a fair amount of Javawork 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 aswhen it runs. If an analysis was done using only first shift information, it would appear a 10processor machine with 5 general purpose processors and 5 zAAPs would be an optimalconfiguration. However, if you look at the same data in the following chart you get a differentpicture.


0 2 4 6 8 10 12 14 16 18 20 22

Hour

0100200300400500600700800900

1000

% o

f a C

P

zAAP % APPLCP % APPL

Potential zAAPUtilization Estimate

This data shows there is a need for 8 general purpose CPs to handle the capacity requirementsfor the non Java workload during third shift If this work must run without delay, then 5 generalpurpose CPs would reduce it’s throughput. If we assume we must have 8 general purpose CPsfor third shift and the total amount of capacity needed for all shifts is 10 processors, it may beappropriate 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 thenormal 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 --- seeAppendix C for further discussion.)

This second chart can provide input to a capacity plan for future processing needs. If theadditional workload will run during third shift and is a non Java workload, then additional CPswill be needed. If the additional workload is Java based and will run during first shift, then azAAP may be a viable alternative. It can provide additional Java capacity for first shift as wellas help offload some of the Java work running on the CPs. This can help provide additional Javacapacity during first shift, and the potential for CP capacity reduction by the Java work mayprovide additional non Java capacity during first shift.

Once this type of analysis is completed, it should provide the information to help drive thenormal capacity planning process.


0 2 4 6 8 10 12 14 16 18 20 22

Hour

0

100

200

300

400

500

600

700

800

900

% o

f a C

P

CP % APPLzAAP % APPL

Potential zAAPUtilization Estimate

Summary:

The zAAP has the potential to deliver high performance Java processing in a cost effectivemanner on the zSeries CEC. This new feature may have a potential impact on the capacityplanning 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 zAAPcapacity planning process. If you have questions about this paper, please contact your IBMaccount team.

Notices:

TrademarksJava is a trademark of Sun Microsystems, Inc.Microsoft and Excel are trademarks of Microsoft Corporationz/Architecture, RMF and IMS are trademarks of International Business Machines Corporation inthe United States or other countries or both. zSeries, z/OS, WebSphere, CICS are registered trademarks of International Business MachinesCorporation 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 capacityplanning process for the zSeries CEC. The information in this publication is not intended as thespecification of any programming interfaces provided by z/OS. See the publication section ofthe IBM programming announcement for the appropriate z/OS release for more informationabout what publications are considered to be product documentation. Where possible it isrecommended to follow-up with product related publications to understand the specific impact ofthe information documented in this publication.

The information contained in this document has not been submitted to any formal IBM test andis distributed on as “as is” basis without any warranty either expressed or implied. The use ofthis information or the implementation of any of these techniques is a customer responsibilityand depends on the customer’s ability to evaluate and integrate them into the customer’soperational environment. While each item may have been reviewed by IBM for accuracy in aspecific 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 withno other processing occurring and do not represent actual field measurement; therefore, theresults which may be obtained in other operating environments may vary significantly. No© 2005, IBM Advanced Technical Support Techdocs - Washington Systems Center 11/14/2006 http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP100417Capacity Planning Considerations for zAAPs Page 12

commitment as to your ability to obtain comparable results is in any way intended or made bythis release of information.


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 projectionfunction. That level can be obtained athttp://www-1.ibm.com/servers/eserver/zseries/software/java

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 andtotal values at termination. Each output file is intended to contain the data for only thatjob/address space or each JVM depending on scenario. An example of the output messages isthe following: IFA Projection data for system id=<SYSD.50594238> Starting at: 18:31:30 - Current address spaceCPU: 0.008068 sec.<SYSD.50594238> Interval at: 18:36:30 Switches To/From IFA: 3717251 Java IFA: 99.3 sec. JavaStandard CPU 101.86 sec. Interval address space CPU: 208.66 sec.<SYSD.50594238> Interval at: 18:41:30 Switches To/From IFA: 3903114 Java IFA: 104.27 sec. JavaStandard CPU 106.95 sec. Interval address space CPU: 219.09 sec.<SYSD.50594238> Interval at: 18:46:30 Switches To/From IFA: 4176332 Java IFA: 111.57 sec. JavaStandard CPU 114.44 sec. Interval address space CPU: 234.43 sec.<SYSD.50594238> Interval at: 18:51:30 Switches To/From IFA: 3842225 Java IFA: 102.64 sec. JavaStandard CPU 105.28 sec. Interval address space CPU: 215.68 sec.<SYSD.50594238> TOTAL at: 18:51:30 Switches To/From IFA: 15638922 Java IFA: 418 sec. JavaStandard CPU 429 sec. Total address space CPU: 878 sec.

The key fields of interest for performance analysis are the following:

Time accumulated for Java threads processing zAAPJava Standard CPU

Time accumulated for Java threads processing zAAPeligible work. Please note it is possible for the JAVA IFAtime to exceed the interval address space CPU time. This isdue to the fact the JAVA IFA time is accumulated each timethe task switches back to being eligible to run on the generalpurpose CPs. The interval address space CPU time isaccumulated at the conclusion of each interval. If there is along running Java thread which does not switch back to runon a general purpose CP during an interval, it’s Java IFAtime will not be recorded in that interval. Thus the Java IFAtime reported could have been consumed in a previousinterval. This will often show up for threads which do notterminate until the JVM ends. In this case, all of their JavaIFA time can show up in the last recorded interval and thevalue will often be larger then the interval address spaceCPU Time for the last interval.

Java IFA

State changes in processing of zAAP eligible work versusnot eligible work for all Java threads in the JVM

Switches To/From IFA


Time for all work in the address space across alldispatchable units including the Java threads

Interval address space CPUnon-eligible work

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 ofthe IBM SDK for z/OS, Java 2 Technology Edition, V1.4, program product 5655-I56 with thePTF (or later) for APAR PQ86689. New run-time options for this capability at this productversion are planned to be added with the -Xifa options. Command line options that start with -Xrefer to nonstandard Java interpreter options and are anticipated to be unique to IBM and/orz/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 isdesigned 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 qualifyingwork and a switch request from a zAAP to a general purpose processor when nonqualifyingwork 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 toSTDERR at intervals of n minutes. A value of 0 indicates information should only be writtenwhen Java terminates. Note: the interval requested is not honored exactly. Messages are writtenafter a switch has been encountered for work considered eligible for offload or returning fromthat state.As a result, messages may be delayed during idle periods. This option is honored on allversions of z/OS but is primarily intended for assessing potential zAAP use on versions beforez/OS 1.6. z/OS 1.6 has function to include zAAP capacity planning information in SMF/RMFrecords.

-Xifa:force Designed to force Java to continue attempting to use zAAP, even if none areavailable. This would typically be specified for the purpose of collecting RMF/SMF data toassess potential zAAP use. This option is honored only with the zAAP support delivered withz/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 outputdescribed in the previous section.


Java5 JVM on z/OS

The Java5 JVM implementation on z/OS does not support the -Xifa:projectn option. Since theJava5 JVM requires z/OS 1.6 or higher, there are two options for obtaining zAAP usageestimations, 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 itrequires updating the JVM arguments for all copies of the JVM and subsequently removing theoption when finished.

Option 2:The FMID which enables System z Integrated Information Processors (zIIPS) also brings newfunctionality to allow you to estimate zAAP usage without setting any additional JVMarguments. This functionality is provided by FMID JBB77S9 (z/OS 1.6) and JBB772S (z/OS1.7). Further information is available at:

http://www-03.ibm.com/systems/z/ziip/about.html

The zAAP and zIIP estimation information can be obtained from the RMF Workload ActivityReport 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 1or 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 20.32 MPL 0.30 EXECUTION 2 … CPU 581337 SRB 0.0 AAPCP 17.11 ENDED 14237 QUEUED 0 … MSO 0 RCT 0.0 IIPCP 0.00 END/S 118.64 R/S AFFIN … SRB 0 IIT 0.0 #SWAPS 0 INELIGIBLE 0 … TOT 581337 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 toestimate the zAAP usage for each WLM service class. In this particular example, the enclavesrunning in this report class consumed 20.32% of an engine in the reported period, 17.11% of anengine is zAAP eligible ( 84% of the enclave activity in this period is zAAP eligible).


You can also easily estimate the total zAAP usage across all service classes in a z/OS image byusing 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 thedesignated system and allow you to easily estimate the zAAP and/or zIIP workload across allservice classes on the z/OS image.


Appendix B: The Microsoft Excel Workbook

A spreadsheet summarization tool is available to assist in the analysis of the zAAP ProjectionTool Output. This Microsoft Excel workbook, zAAP projection tool workbook.xls, can readthe 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 bysome other means. Since Websphere uses several address spaces, each of which will produce aJava log, an Excel workbook is a good means to organize the data and to do analysis such ascombining projection data sheets from multiple address spaces.

The zAAP Projection Tool workbook can be downloaded from the same website as the zAAPProjection 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:

The zAAP Projection Tool workbook is designed to provide the following capabilities:

Capability to combine data from multiple JVMsSeconds of zAAP eligible processing, non zAAP-eligible (standard CP) processing, and totaladdress space time for the Java space(s). Combines data from multiple address spaces, service classes and LPARsCombines the data and aligns to intervals such as the RMF interval used. Ability to adjust zAAP utilization factoring in z/OS capture ratioszAAP and standard CP time expressed as a percent of the engine (single CP) the data wascollected on. This can be used as input to the projected number of zAAPs needed factoringin a target maximum utilization to ensure workload responsiveness.


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:00 99 102 209 48% 33% 34% 70% 39% 52%SYSD test1 18:36:00 104 107 219 48% 35% 36% 73% 41% 55%SYSD test1 18:41:00 112 114 234 48% 37% 38% 78% 44% 58%SYSD test1 18:46:00 103 105 216 48% 34% 35% 72% 40% 54%

It is really the SDP (saturation design point) value which is discussedin the workbook documentation. The concept of the SDP is to set anupper value of how busy you want a zAAP to get. For example. Ifyou want to make sure the zAAP never gets more than 80% busy, youwould set cell N2 to 80%. The actual % busy of the zAAP is dividedby this value. If the resulting cell is 100% it says you have consumedas much of the zAAP as you wish. Some people feel, because thezAAP may only process high priority work, you might not want to limitit's utilization. This column could be used to see how close you are tothis value.

zAAPs w/wait

This column is the % of a zAAP engine which could be used with thecapture ratio applied. Since CPU time is captured time, it does notinclude the MVS uncaptured time. Normally a customer will calculatea capture ratio ( the difference between the total time used on amachine versus the captured time (TCB+SRB time)) and apply it to thecaptured time to estimate the total amount of time an address spacedused. This column is included if the customer wants to use it. Theworkbook allows you to update the capture ratio which is set to 90% bydefault. The capture ratio is specified in cell M2

zAAP% w/capt ratio

This column is the % of a CP being used by the address space duringthe interval.

Appl% engineDescriptionWorkbook Column


Appendix C: Additional Tuning and Planning Considerations

APAR OA14131 is providing enhancements to the z/OS dispatcher to help make better use of thezAAP processor. Please review WSC Flash 10432 (z/OS: Dispatcher Enhancements forzAAPs) 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 switchedbetween standard processors and zAAPs. Two new parameters can be defined in the IEAOPTxxmember of SYS1.PARMLIB.

Yes WLM will manage the priority of zAAPeligible work for standard processors.Initially WLM will execute both zAAP andnon-zAAP eligible work in priority order forstandard CPs. The exception is when thecustomer is using software pricing with SCRTwith a WLM managed cap on capacity.When the cap is limiting capacity, WLM willnot allow standard CPs to process zAAPeligible work.No specifies zAAP eligible work can run onstandard processors but at a priority lowerthan any non-zAAP work

IFAHonorPriority=Yes|No

Yes specifies zAAP-eligible work mayexecute on both standard processors andzAAPs. No specifies standard processors may not runany zAAP eligible work unless there are nozAAPs operational in the partition.

IFACrossOver=Yes|No

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 theinstallation 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. Thismay have an impact on performance.

2. Reduce software cost as much as possible, but allow Java work to use excess general purposeCP capacity if needed.

3. Continue to provide optimum performance for Java workloads while reducing software costif possible.


As these parameters will influence the dispatching of work on the standard CPs, they will affectyour capacity requirements for the standard CPs and zAAPs. Allowing crossover will permitJava work to compete for standard CP resources in addition to executing on zAAPs. The amountof Java crossover onto the standard CPs will be affected by the HonorPriority setting. IfHonorPriority is desired, then Java work can be dispatched ahead of any lower priority non Javawork. If HonorPriority is not desired with crossover, then the Java work can only use availableCP 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 thetracking 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 beappropriate if there is ample planned zAAP capacity or the preference is to fully utilize thecheaper zAAP resource. The utilization of the zAAPs may match up closer to the capacityplanning projections generated with the measurement tooling and spreadsheet analysis describedin the earlier sections of this paper. However, preventing crossover can eliminate the flexibilityto use standard CP cycles if standard CP resource is available and can prevent the execution ofadditional Java work if the zAAP resources are fully utilized.

In addition to the capacity planning considerations, the CPU utilization of the standard CPs willchange 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 shouldconsider using IFACrossOver = NO. All eligible Java work will run on the zAAP. There is thepotential for eligible Java work to wait to gain access to the zAAP CP when general purpose CPcapacity is available.

If the objective for the zAAP is to maximize performance of Java workload and reduce softwarecost if possible ( option # 3 ), you should consider using IFACrossOver = YES andIFAHonorPriority = YES. This will allow the general purpose CPs to select the highest priorityready work regardless of workload type.

If the objective for the zAAP is to reduce software cost as much as possible while maintainingperformance ( option # 2), you should consider using IFACrossOver = YES andIFAHonorPriority = NO. This will allow the general purpose CPs to select Java work only ifthere is no other work ready to run. Thus, as long as any CP is available, the Java work will bedispatched.


Appendix D: LPAR Weight Management Considerations

Physical CPs can be dedicated to a single partition or shared by multiple partitions. The amountof CPU resource guaranteed to a shared partition is defined by the weight specification. Thefollowing 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 )

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.


1,000TOTAL30% * 10 = 3(300/1000) = 30300ZOS320% * 10 = 2(200/1000) = 20200ZOS250% * 10 = 5(500/1000) = 50500ZOS1

Equivalent CP Capacity% CPU ResourceWeightPartition Name

100TOTAL50% * 1 = .5(50/100) = 5050LINUX250% * 1 = .5(50/100) = 5050LINUX1

1DedicatedICF11,000TOTAL

30% * 10 = 3(300/1000) = 30300ZOS320% * 10 = 2(200/1000) = 20200ZOS250% * 10 = 5(500/1000) = 50500ZOS1


Now lets add a zAAP to be shared by partitions ZOS2 and ZOS3. The zAAP CP is managed outof the ICF pool but inherits the weight specified for the general purpose CPs of the partitions it issupporting. The above sentence is true for the z990 and z890. The zAAP CP is managed out ofits own pool on the System z9. As such, the need to manipulate the weights discussed below isnot needed on a System z9 processor. If there are no adjustments to weights notice the amount ofCP resource and % CPU Resource available to each partition in the ICF pool.

You see the Linux partitions have lost capacity with the addition of the zAAP processor. This isdue to the fact the zAAP weights are not specified in the HMC definitions but are inherited fromthe HMC definitions for the general purpose CPs. This obviously is not what we want. In orderto guarantee the Linux partitions the same amount of CP resource we need to adjust the weightsfor the ICF shared pool. Since we can not change the weights for the zAAP CPs, we MUSTchange the weight for the other CPs.


600TOTAL50% * 2 = 1(300/600) = 50300ZOS3

33% * 2 = 0.66(200/600) = 33200ZOS28% * 2 0.16(50/600) = 0850LINUX2

8% * 2 = 0.16(50/600) = 0850LINUX11DedicatedICF1

1,000TOTAL30% * 10 = 3(300/1000) = 30300ZOS320% * 10 = 2(200/1000) = 20200ZOS250% * 10 = 5(500/1000) = 50500ZOS1


Since we added 1 zAAP CP to the pool and added a combined zAAP weight of 500, then asingle CP in the ICF pool must equate to a weight of 500. Once we know this value, we canrecalculate the weight for the other ICF pool shared CP Partitions. The following formulae isused to determine the new partition weights:

Partition Weight = Equivalent CP Capacity ( For the Partition) * Weight of a Single CP ( Forthe ICF Pool)

Lets use this formulae to update the LPAR weight definitions

These new LPAR weights now guarantee the Linux partitions the same amount of CP resourceas they had prior to adding the zAAP CP and the zOS partitions are guaranteed the amount ofthe 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 morethan one type of workload ( ICF, IFL or zAAP ). If all the ICF pool CPs are dedicated thiscalculation is not needed.


1,000TOTAL30% * 2 = 0.6(300/1000) = 30300ZOS320% * 2 = 0.4(200/1000) = 20200ZOS225% * 2 = .5(250/1000) = 25250LINUX225% * 2 = .5(250/1000) = 25250LINUX1

1DedicatedICF11,000TOTAL

30% * 10 = 3(300/1000) = 30300ZOS320% * 10 = 2(200/1000) = 20200ZOS250% * 10 = 5(500/1000) = 50500ZOS1


z/os performance: capacity planning considerations for

Documents