You can see from the previous overview that many factors are involved in the sophisticated methodology BEST/1 uses for predicting storage requirements. Many
●
✚
▲
✚✚
✚ ✚
✚ ✚
●
●
●
●
▲
▲
▲ ▲ ▲
Figure 106. Synchronous Reads/Transaction vs. Resident Set Size
Change Paging Behavior Paging behavior . . . : *GENERIC
Type changes, press Enter. If any values are changed, Paging Behavior field is set to *USER. If working sets or paging exponents are changed, paging coefficients are set to 0.
Working set size . . . . 3.3 M B Database Non-DB Paging exponent . . . . 2.0 2.0 Paging coefficient . . . . 2.0 2.0
F3=Exit F12=Cancel
Figure 107. Change Paging Behavior Display
Chapter 7. Modeling Changes to the System 139
of these can be viewed, changed, or both, as the analyst has additional information for BEST/1 to consider.
Change the guidelines for the appropriate CPUs by the ratio of synchronous reads to pool faults. For example, if the measured synchronous reads are 50 and the pool faults are 30, the ratio is 1.67 and you should raise the guidelines by 67%.
Dealing with conservative Work Management Guidelines
Your experience may indicate that the performance at your installation can be satisfactory with higher page fault rates than what is recommended in the Work Management book. If the work management CISC and RISC guidelines and thresholds are too conservative, increase the values on the Edit Sync Reads Guidelines display to reflect a higher number of sustainable sync reads. If you are analyzing only CISC CPU models, then only the values in the Guideline column need to be increased. If you are analyzing only RISC CPU models, then only the values in the Threshold column need to be increased.
Note: Consider using *NONE or *NONE combined with specific workload response time and throughput objectives to override memory upgrade analysis.
Dealing with synchronous reads that are not due to page faults
BEST/1 considers synchronous reads to be caused by page faults. You can use one of the two approaches when there is a substantial difference between the measured number of pool faults and synchronous reads (as seen in the performance monitor report or in the CRTBESTMDL job log).
1. Edit the sync reads guidelines to reflect the actual ratio of synchronous reads to pool faults. You can find this ratio of synchronous reads to page faults for each pool in the CRTBESTMDL job log. This is appropriate because the values normally seen in the Edit Sync Reads Guidelines display, as seen in Figure 108 are work management guidelines for pool faults whereas BEST/1 is comparing
Edit Sync Reads Guidelines
Type changes, press Enter. Values are used for Analysis recommendations.
Check sync reads . . . . Y Y=Yes, N=No ---Pool 1 (*MACH)---CPU relative performance Guideline Threshold 2.0 or less . . . . 2 10 Greater than 2.0 . . . . 2 10
---All Other Pools---CPU relative performance Guideline Threshold 2.0 or less . . . . 15 75 3.0 or less . . . . 25 75 10.0 or less . . . . 35 150 30.0 or less . . . . 80 300 50.0 or less . . . . 180 400 100.0 or less . . . . 250 400 Greater than 100.0 . . . . 300 400
Bottom F3=Exit F12=Cancel
*CISC CPU MODELS USE *GUIDE VALUES, *RISC CPU MODELS USE *THRESH VALUES
Figure 108. Editing Sync Reads Guidelines
the number of sync reads with guidelines for faults. You can access the Edit Sync Reads Guidelines display by selecting option 11 (Analysis parameters menu) from the More BEST/1 options display. Then select option 2 (Edit sync reads guidelines).
2. If a substantial percentage of synchronous reads are not affected by availability of memory, then you should move those synchronous reads to synchronous writes so that the number will not change as load on memory changes, and set the paging coefficient to zero. The paging coefficient is recalculated next time the model is analyzed. See “Changing Functions and Transactions” on page 116 for more information on the Change Transaction display.
If 40% of synchronous reads are not related to memory congestion, move 40%
of the sync reads to sync writes. After the paging coefficient has been set to zero and the model reanalyzed, the sync read values on the Main Storage Pool Report should match the measured pool fault rate. This may affect DASD results adversely if you are modeling RAID, mirroring, or checksum protection because IOs are added for all writes or permanent writes.
Notes:
a. Do not use this approach if checksum or mirroring protection is being modeled, or when modeling high availability disks (such as 9337, 660x-070 models).
b. Make these changes to the baseline model only. Do not make them after you have made “What-if...?” changes, such as a change in the configuration or workload objective.
Dealing with transaction specific paging behavior
BEST/1 uses the indicated paging behavior profile for each transaction to determine the effect of reduced storage on each transactions sync reads rate.
Review the paging behavior indicated for each transaction (particularly for transactions that run in the pools which are predicted to have substantial sync read rates) to see if the types are appropriate. If they are not appropriate, provide better values for paging exponent and working set size. If you change paging exponent and working set size, the paging behavior changes to *USER automatically. Use the Change Paging Behavior display, as shown in Figure 107
on page 139 which you can reach from the Change or Create Transaction displays by pressing F13 (Change paging behavior).
After making these changes, be sure to set the paging coefficient to zero for the transaction.
On the Change Paging Behavior display, decreasing the working set size value means transactions require less memory, therefore paging will decrease.
Conversely, increasing the working set size means transactions require more memory therefore paging increases with less memory available.
The higher the paging exponent, the quicker the fault rate increases as available memory decreases as seen in Figure 109 on page 142.
Chapter 7. Modeling Changes to the System 141
Note: Make these changes to the baseline model only. Do not make them after you have made “What-if...?” changes, such as a change in the configuration or workload objective.
Dealing with inappropriately sized pools and activity levels
When calculating resident set sizes for transactions, BEST/1 uses the pool activity level, in addition to the pool size, average number active in the pool and the number of active jobs in the pool. If the pool activity level is set without regard to available memory in the pool, then these calculations might be incorrect.
Check and set the pool activity level to roughly the number of jobs that can run concurrently in the pool, while maintaining reasonable paging performance.
You should also provide the working set size estimate for the transactions to guard against the problems that arise when the pool contains excessive amounts of memory as compared to what is required for the specified activity level.2
Change the paging coefficient to zero after making these changes.
When BEST/1 is making pool-by-pool determinations of which pools need how much additional storage, it will never decide to remove storage from a pool. If a pool is excessively configured, the analyst should remove the excess storage and thus possibly reduce BEST/1’s overall storage recommendation.
2. The difficulty arises due to lack of measurement data to indicate the amount of memory a transaction receives in a pool. BEST/1 estimates this value, based in part upon activity levels that the user can modify, to deal with two opposite situations:
– Suppose pool 3 is used by only one job whose working set is 2 MB. The pool activity level is 10 and pool size is 2 MB. BEST/1 assumes it should allocate 2 MB to a larger number of jobs (between 1 and 10, approximately 4) and gives the job about 600 KB. However, in the real system the job would have gotten all of the 2 MB. The solution in this case is to set the pool activity level to 1.
– Suppose pool 4 has 20 MB of memory with an activity level of 1, but in the measured interval only 1 job was active that has a 4 MB working set. If all of the pool 4 memory is allocated to that single job, it will get a 20 MB resident set. In a″What-if...?″
situation when 1 more active job is added, BEST/1 reduces the amount of memory that each job gets to perhaps 10 MB and computes large page fault counts for each of them (4 times for each job). However, in a real system for each job, there would have been no change in the number of page faults. The solution in this case is to provide the working set size (4 MB) for the transaction as part of the paging behavior for the transaction.
✚
▲
●
✚
✚
✚ ✚
✚
✚●
●
●
●
● ● ●
▲
▲
▲
▲ ▲
Figure 109. Resident Sets with Paging Exponents
Note: Make these changes to the baseline model only. Do not make them after you have made “What-if...?” changes, such as a change in the configuration or workload objective.
Chapter 7. Modeling Changes to the System 143
Chapter 8. Selected Modeling Topics
This chapter shows the basic procedures for special modeling topics including:
v Client Access
v Release level performance improvements
The information in this chapter assumes all previous chapters have been reviewed, particularly Chapter 3. Building a Model Using Measured Data, Chapter 6. Model Analysis and Calibration, and Chapter 7. Modeling Changes to the System.
Not all displays that are used when modeling measured data are shown. However, the displays that have some relationship to Client Access functions are shown with comments. In this example, performance data included other work in addition to Client Access work. This is done so that the entire system environment is modeled, not just Client Access functions.