5. How do I interpret PM for System i reports in an LPAR environment?
PM for System i Logical Partitioning (LPAR) Considerations
PM for System i has limited support for the implementation of LPAR in customer using OS/400 Version 4 Release 5, Version 5 Release 1 or Version 5 Release 2. The performance data collected is based on each individual partition which transmits, so any reports produced can only reflect the performance and utilization characteristics of the partition involved. There is no facility available to provide a "rolled up" view of the entire system.
Please Note: If you are using only one partition (no LPAR) all information is reported accurately.
Important: Machines that have LPAR implemented, must collect performance data using Collection Services for accurate LPAR reporting.
Processor Assignment
LPAR allows the number of processors assigned to a partition to be changed and therefore it must be recognized that if this is done during the reporting period, either across the month or during the days of that month, any predictions will be based on that profile being consistent across the following days and months. This may not always be the case.
Interactive Feature Card(s)
On a system which has implemented LPAR the interactive processing capacity is allocated across the partitions on a percentage basis. The Executive Summary Graph (150) and Management Summary Graphs (175) will show the utilization percentage of the amount of the Interactive Capacity assigned to that partition and will base their predictions of the Months to Guideline on the same criteria. The same consideration about the processor allocation profile as mentioned above applies.
Disk Allocation
Just as the number of processors and percentage of the interactive feature cards allocated to a partition can be readily changed, it is also possible to change the amount of disk allocated. Trend calculations for disk utilization are based on the disk storage profile remaining constant and this must be considered when evaluating the relevant reports.
Total System View
PM for System i cannot present a "rolled up" view of the total system. This is because some of the underlying measurements are not yet present. For example, on these releases there is no cross-reference to the primary system time to allow the offsetting of performance data from the other partitions which is a fundamental requirement to present such a consolidation.
Total System Implications that can be inferred from PM for System i data reported by Partition:
What is possible today? There are some conclusions which can be drawn from the PM for System i performance data but this is not automatically consolidated. It is necessary to include two caveats here:
- Unless all partitions are reporting their performance data, no conclusions can be drawn about the total system.
- Unless all partitions are operating with their system clocks set to the same time as the processor, utilization becomes much more difficult to analyze and the offset calculation must be performed manually..
DASD Reports:
As these present a view of the average amount of DASD space used in each partition during the reporting period the time displacement is of little consequence. All partitions will almost certainly have a different amount of DASD assigned to them so it is not legitimate to simply average the utilization show for each partition. What must be done is to convert the utilization percentages to "used" and "available" Gigabytes or Megabytes for each partition and then sum these values. This will then show the percentage of the total system's DASD is being used. For example:
|
Partition Number
|
Total DASD (MB)
|
PM for System i Percentage Used
|
Amount Used (MB)
| |
1
|
80,000
|
50%
|
40,000
| |
2
|
50,000
|
80%
|
40,000
| |
3
|
30,000
|
40%
|
12,000
| |
4
|
70,000
|
60%
|
42,000
| |
Total
|
230,000
| |
134,000
|
The PM for System i reports for each partition will show you if a particular partition is DASD constrained and this simple table will indicate if your system is constrained or not. This particular example shows although your total system's DASD is only slightly over 58% utilized (134,000/230,000), partition 2 is approaching a critical situation while the other partitions appear to have space to spare. Subject to granularity considerations it might be appropriate to reassign DASD from part partitions 1, 3 or 4. In this case, moving say 10,000 MB from partition 4 to partition 2 would result in utilization values of approximately 71% and 68% respectively. However, factors such as disk arm utilization and granularity of DASD devices must also be considered.
Processor Reports:
Analysis of these is much more difficult, particularly when there is a real time offset between partitions. On the assumption all partitions have identical date and times on their system clocks then it is possible to calculate a weighted average from looking at the same reports for all partitions. For example:
|
Partition Number
|
Number of Processors
|
Number of Transactions
|
Average Response Time
|
Total Resource (see note)
| |
1
|
4
|
3,000
|
0.50 seconds
|
1,500
| |
2
|
2
|
5,000
|
0.75 seconds
|
3,750
| |
3
|
4
|
8,000
|
1.50 seconds
|
2,800
| |
4
|
2
|
2,000
|
1.50 seconds
|
3,000
| |
Total
|
12
|
18,000
| |
11,050
|
Note: This is not a 100% accurate reflection of what resource is being used but it may prove a useful approximation.
We can therefore say the average response time across all partitions is 0.614 seconds (11,050/18,000). If it were desired to improve the response time for partition 4 then moving a processor from partition 1 or 3 may have the desired effect (a processor upgrade might also be appropriate). However, in most cases where LPAR is implemented the reason processors are allocated to particular partitions is to optimize response time for the users of that partition. To properly understand what is going on in each partition it is probably desirable to utilize one of the more sophisticated performance analysis tools.
If the system date and time across partitions differs, then the calculations become much more complex as the same weighting must be done for each time period across the reporting day and/or month and allowance must be made for the appropriate offset.
|
8. The utilization percentage shown on the Management Summary Graph for "Processor, Interactive" is higher than that shown for "Processor, System + Interactive". How can this be?
They are expressed as percentages of different guidelines. The "Processor, Interactive + System" is calculated as a percentage of the system's total processing capacity while that for the "Processor Interactive" is expressed as a percentage of the system's Interactive Processing Capability.
The reason this is done is to identify when it is necessary to take action to increase the system's Interactive Capacity. As some systems have implemented Feature Cards to provide the Interactive Capacity it would be possible for the "System + Interactive" utilization to be below the guideline but for there to be inadequate Interactive Feature Card capacity on the system.
The "Processor, Interactive" report uses the lower of the guideline based on the Interactive Feature Cards or the guideline based on the "Number of Processors" queuing algorithm. The guideline values on which these two reports are based are shown on the Facts pull down of report 675 "Processor Trend, Interactive". The system's Interactive Card Feature is shown on this graph as a horizontal red line which can be either below or above the guideline based on the number of processors.
|
