gtps3m0j | System Performance and Measurement Reference |
Reports follow that provide the information needed for system performance analysis. The environment and system summary reports appear first. These are followed by the reports associated with each collector.
The Environment Summary Report contains general information about a collection run. Besides the date, the tape volume serial number, and information identifying the complex, information is displayed that defines the system environment at the time and describes the kind of data collection being run.
Figure 2. Environment Summary Report
The options listed in the options chosen part of the Environment Summary Report come from a typical run. This list should not be considered exhaustive. See TPF Operations for more information about the list of options.
The system collector is primarily concerned with the operation of the CPU proper. The items shown in the system summary (see Figure 5) may be considered in groups comprising gross input, system utilization, working storage utilization, and queues or job lists, which make up the priority of processing.
Figure 3. Input Messages by Application Report
INPUT MESSAGES BY APPLICATION SYSTEM WIDE 27 FEB 14:18:27 APPLICATION SSU NAME MSG / SEC MESSAGES PERCENT OF TOTAL AAAA HPN 0.000 0 0.000 APPA HPN 0.000 0 0.000 APPC HPN 0.000 0 0.000 AZAZ HPN 0.000 0 0.000 BBBB HPN 0.000 0 0.000 B32O HPN 0.000 0 0.000 CBM1 HPN 0.000 0 0.000 CBM2 HPN 0.000 0 0.000 CBW1 HPN 0.000 0 0.000 |
Figure 4. Pushbutton Application Summary Report
A set of counters in the control program provides information on the number of high-speed messages started by pushbutton applications. A sample report is shown in Figure 4. The message counters used are never reset, so the counts in this report represent total messages for the applications listed over the entire life of the collection.
The system message counter table (SM) records are used as input to this report. The SM record represents a table of as many as 63 program entries that constitute one RES0 application. Each 8-byte program entry consists of a 4-byte program name and a 4-byte counter field. An SM record is written to RTC tape for each RES0 application for each subsystem user, for each usable I-stream, and for each subsystem. For example, on a system using 2 subsystems and 2 I-streams with 2 subsystem users per subsystem and with 5 RES0 applications implemented and variable MAXAPPL in segment JCD4 changed from 0 to 5, there would be (2 × 2 × 2 × 5 ) = 40 SM records written to tape, both at start and at end time. TPF installations implementing RES0 applications must change segment JCD4 to set variable MAXAPPL to the number of RES0 applications implemented. MAXAPPL defaults to 0. This is done by segment JCD4 (see the SMREC DSECT in JCD4 for SM record layout). The CROSC macro with entry GLBAC is used to retrieve pointers to the global areas where the RES0 application information can be found. The RES0 application information is defined on the pilot tape and updated by the UII package. Note that although SM records are collected by subsystem user, I-stream, and RES0 application, the program groups are unique only by subsystem and by RES0 application number (1 - 5). For this reason, pushbutton applications are reported by subsystem, RES0 application number, and program name only.
Program names and descriptions for additional applications must be entered into the name and description tables DNMTBLC and DMSGDES in segment JRA3 to be reported properly. These tables have a one-to-one correspondence with each other. They are a listing of all programs used by all pushbutton applications. When additional programs are to be supported, their names and descriptions must be inserted into these tables. Because the tables are searched sequentially for each program being reported, the order of programs in the tables is not important as long as each name in DNMTBLC is in the same array position as its description in DMSGDES.
The preceding example assumes that 5 RES0 applications have been defined. Only 1 RES0 application is predefined, and you are responsible for applications 2 through 5, if they are used.
This report provides a summary of the system, of I-streams, of storage, and of shutdown conditions. The items shown in the I-stream Summary (see Figure 5) may be considered in groups that comprise system utilization, activity per I-stream, and queues or job lists that comprise priority of processing.
Figure 5. System Summary Report
Maximum, minimum, and mean values are shown for each variable. For the variables that are continuous counts, reduced to a per second base, the maximum and minimum values are actually mean values for a single collection interval. The mean values are the mean of all the intervals, that is, a mean of all the interval means. The maximum and minimum values are indicative of the degree of variation that occurs in system load. Extreme values should lead one to the plot reports in which individual interval values can be examined. Note that the maximum and minimum values for different variables do not necessarily occur during the same interval.
For mean values, a long interval has a smoothing effect on the peaks and valleys of a sample set. For example, a peak might show a much higher maximum for a one-second interval than for a 15-second interval. Appropriate run lengths, periods, and intervals must be chosen to provide detailed data for each individual requirement.
The shutdown levels for system resources are established as absolute numbers of system resources. These levels can be redefined using the ZCTKA command:
The list should be kept current and readily available for the analyst working with the data reduction reports. A record of all changes to these values should be maintained in a history file so that reduction reports for a particular calendar time period can be analyzed with respect to the proper level setting.
Inputs are shown on a per second basis and consist of:
If utilities such as schedule change or file maintenance and no unit record tasks are run during data collection, the results of the reduction will be skewed by the load supplied by these utilities (one input message could produce an inordinate amount of file activity).
The ratio of one type of message to another is constantly changing. To relate one data collection to another, or one system to another, a common denominator is needed. Therefore, all message types, except TCP/IP native stack input messages, are expressed in terms of high-speed messages. See TPF Transmission Control Protocol/Internet Protocol for more information about counts for TCP/IP native stack messages.
The weighted message rate is calculated using the following factors:
System services messages are not included in the weighted message rate because they are considered network overhead and are reported solely for information.
Created entries are not included in the weighted message rate because the majority are generated by, and considered to be part of, some other, external message that is already counted.
The weighted message rate algorithm is as follows:
WEIGHTED MESSAGE RATE = (HS MSG PROC) - (HS MSG ROUT) + (LS MSG * WT) + (HS MSG ROUT * WT2) + (TCP/IP WEIGHTED MSG)
Weighting factors WT and WT2 are preprocessor statements entered during SIP time which may be adjusted for each system. However, the most commonly used value for WT is 5. The most commonly used value for WT2 is 0.3; therefore, WT2 is coded as 3 in the DATACO macro.
Experience with existing systems indicates that a teletype message requires four to five times the processing required by a high-speed message; therefore, most systems use the default value. Processing required by the average routed message is roughly three-tenths (.3) of that required by the average high-speed message. Again, most systems use the default value.
Weighting factors may also be established for a given TPF system through the real-time trace facility. Message types may be sized by comparing number of ENTERs, FINDs, FILEs, MACROs, and so on. Total processing by message type is not easily available without special software or hardware monitors. The comparison method yields satisfactory approximations for weighting purposes.
Resource utilization per message involves two parameters: CPU busy time per weighted message as determined previously, and the number of bytes of working storage per active ECB. Frames allocated for system heap are not included in the number of bytes of working storage in use for this calculation. CPU busy time per weighted message is obtained by dividing TPF Processor Utilization by the Weighted Message Rate.
In the System Summary Report, PAUSE COUNT is the number of times per second that the main I-stream intentionally ran exclusively. For a multiprocessor, this is also the number of times all application I-streams were paused. Pausing has no impact for uniprocessors because there is only a main I-stream. The information is nevertheless provided as a migration aid. MAIN I-STREAM WAIT TIME (MILS) is the amount of time that the main I-stream spent waiting for other I-streams to be paused. The TIME SPENT WORKING WHILE PAUSED (MILS) is the amount of time that the main I-stream was actually working while all other I-streams were paused. The CPU utilization stated on the system summary computes utilization using idle time and collection interval time.
For the I-Stream Summary Report, data collection shows the processor utilization at each level and state and, in addition, gives TPF processor utilization. Data Collection uses the time-of-day (TOD) clock to accumulate elapsed time in 12 idle levels for the TPF system, including the wait state. The idle levels indicate if available working storage is too low or system activity (number of active ECBs) is too high. Idle Level 11 shows the percentage of time that the system (as far as TPF is concerned) is truly idle; that is, the control program has scanned the entire CPU loop and found no work to be done. In addition, the idle times greater than zero will also be listed on the I-Stream Summary Report. The I-Stream Summary Report contains three utilization values. The first is calculated the same as for the system summary. The second (smoothed) utilization is the mean value of the utilization used by the work scheduler. The third (adjusted) utilization is calculated in the same manner as the CPU utilization on the I-Stream Summary Report, except that the time spent processing either DLAYC or DEFRC macros is subtracted from the utilization. The amount of time subtracted for each macro processed is an estimate based on the DEFRC or DLAYC and any associated processing. The intent of reporting the adjusted utilization is to show the effort the TPF system is using to process actual work.
The control parameters that trigger the various idle levels are established at system initialization time and must be adjusted for a particular system. The parameter settings are a compromise that allow maximum utilization of resources yet protect the system from catastrophic resource depletion during peak conditions. Any significant idle occupancy on levels 1-12 warrants investigation. This means that either the parameters are too restrictive or the system is approaching maximum capacity because of working storage depletion.
Finally, when there is no work for the system, the system enters the wait state.
The collection interval is the actual duration of the sample rather than the specified duration. The specified and actual duration should be very nearly the same, but there may be some conditions that will cause slight variations in the actual duration.
The various lists appearing in the System Summary represent the job queues that are associated with the CPU loop. The sequence in which they appear also indicates the priority given to each type of job. The maximum, minimum, and mean values represent an actual count of the items taken twice during each data collection interval for sampling mode, and once for continuous mode. To analyze the list data, one must be knowledgeable of the CPU loop and the types of jobs placed on each of the lists by the control program. Because systems vary widely with regard to resources and load, it is difficult to quote numbers that one would expect to see on a particular list. However, guidelines may be established, and any significant variance warrants detailed analysis.
The low-priority ECB classification display shows the number of ECBs running for priority classes defined in the system. A priority class is assigned to an ECB when the LODIC macro is issued.
This is a snapshot of the instantaneous activity in the system. The number of active ECBs is snapped twice during each interval in sampling mode, and once per interval in continuous mode. The active ECBs include the ECBs used for data collection, and those used for unit record tasks. Data reduction subtracts the data collection ECBs, and the ECBs used for unit record tasks to determine the number of truly active ECBs.
When related to inputs, the ratio of active ECBs to weighted message rate is an indicator of message life in the system, or throughput, excluding line queue and transmission times.
Active Messages = 10
Weighted Message Rate = 20 per second
Therefore, the average message life in the system is one-half second or 500 milliseconds. Long mean message life might indicate a bottleneck, which could be because of insufficient working storage, improper program allocation, insufficient number of files, large file queues, and so on.
The maximum allowable number of active ECBs in a system is a control parameter that is established at initialization time. As with all control parameters, this number must be adjusted for each unique configuration. It must be high enough to allow full utilization of resources, yet low enough to protect the system during overloads. Correlation of active ECBs with message rates, working storage occupancy, idle occupancy, and input list helps eliminate the trial and error method of fine tuning all control parameters. ECBs that can be time-sliced are recorded here, along with the number of time slices that occur per second. ECBs are marked as being available for time slicing by the TMSLC macro.
To help ensure that there are enough threads defined to the TPF 4.1 system for any application that uses threads, data is collected from the following fields:
The maximum number of threads active in any process at any time during an iteration of data collection
The maximum number of threads active in any process at any time during the current initial program load (IPL).
If a thread application, such as remote procedure call (RPC), is using a large number of threads compared to the number defined in keypoint A (CTKA), you can enter the ZCTKA ALTER command to change the maximum number of threads.
The possible complexity of the system operation and the amount and type of data collected could lead to questions of interpretation and meaning. For that reason data collection printouts include the equations used to compute:
The total working storage and the ratio of the number of one size block to another will vary from system to system. These parameters are adjustable and established at system initialization time. The number of blocks assigned to each pool is also printed on the System Summary Report.
In the System Summary Report, block occupancy (utilization) is expressed in two forms. The minimum, maximum, and mean block occupancies are expressed as decimal fractions (blocks in use or blocks allocated). Mean available block figures are the average of the actual number of blocks allocated but unused. As with all data collection variables, block occupancy must be related to other variables in order to be meaningful.
For each block size, the mean number in use multiplied by the number of bytes per block equals the mean bytes per pool in use. When the sum of all pools is divided by the number of active messages (as shown in the System Summary Report) the amount of working storage used on a per-message basis should approach system design criteria. Any great variance should be investigated.
Assume that the ECB Block Occupancy is 10% and Idle Occupancy at Level 1 is quite high. Level 1 indicates that the system is not servicing the input list because of an insufficient number of available ECB blocks, yet the ECB pool is only 10% utilized. This indicates that the CPU loop parameter stating the number of ECB blocks that must be available is set too high, or the system is experiencing very unusual peaking conditions that are not reflected in mean utilization of the working storage pool.
The maximum number of frames on the frames pending list is collected to help determine if additional 4-KB frames are needed. If the maximum number is greater than 10% of the frames in the TPF 4.1 system, a system shutdown can occur because it is low on available frames. Frames that are released by threaded ECBs are placed on the frames pending list until it is safe to reuse them; for example, after a purge of the translation look-aside buffer (PTLB) is performed on all I-streams. If a large number of frames remain on the frames pending list, additional 4-KB frames can be generated in the TPF 4.1 system. See TPF System Generation for more information about the CORREQ macro.
Data is collected on the following activities for TPF transaction services:
Track buffers are main storage buffers that are used by the log manager as a holding area for recovery log data. Track buffers hold requests to write to the recovery log before the requests are written to the DASD surface. This process permits the log manager to achieve better throughput by writing 1 track at a time. Buffer allocation factors are directly related to buffer blocked conditions. Track buffers are also used to read data during log recovery.
Increase the number of buffers you have allocated (using the ZCTKA command) if you need to lower the number of blocked conditions.
The recovery log fixed file records can be located either on the basic subsystem (BSS) or on a user-defined subsytem.
These records define the recovery log. They are processor unique and must reside on a single device type. Factors for allocating these records are related to the amount of outstanding commit scope data in the system. A measure of the outstanding data is the amount of recoverable data on the log, which translates into the number of tracks in use.
This number is determined by dividing the number of records allocated for the recovery log by the number of 4K records contained on a single track of the device where the log resides. This value is useful in determining when the size of the recovery log should be increased.
This is the number of recovery log tracks reserved for log recovery processing. This value is equal to 10% of the allocated tracks but not less than 50. This value is useful in determining when the size of the recovery log should be increased.
This count indicates the amount of recoverable data on the recovery log. Because the recovery log is processed as a wraparound file, there is a danger that the log manager will overwrite valid recoverable data. The TPF system prevents this by keeping track of the number of tracks in use and causing a catastrophic dump when the count reaches a maximum value. The maximum value is defined as the total number of tracks allocated minus the number of tracks reserved for recovery. You want to keep the total number of tracks at a high enough level to ensure that the recovery log will not become full. For example, if you have a system with 400 tracks minus the 50 tracks that are kept as a recovery buffer, and the number of tracks in use is 343, you want to increase the number of log records that you have allocated.
This number will be 0 if you do not specify a maximum number. (0 means that the maximum number is unlimited.) If the commit scope gets to the maximum size, the TPF system dumps and the ECB exits.
This is the largest size commit scope that has existed in the TPF system since the last IPL. Use this number to see how close you are getting to the maximum value.
A blocked condition indicates that the log manager track buffer area is not large enough to hold all of the log write requests. During these blocked conditions, the TPF system suspends any ECBs that are in the process of committing data and forces them to wait until buffers are free. Buffers become free when they have been successfully written out to file. A high amount of blocked conditions could indicate a performance problem. If you have a high number of blocked conditions per second, you need to define more recovery log buffers.
As noted previously, control parameters are used to insure that maximum utilization of system resources can be realized, while at the same time protecting against irrecoverable conditions caused by inordinate peak loads. For instance, there is little to be gained and much to be lost by activating a message from the input list when the system activity (indicated by the ECB count) is already very high or the number of available working storage blocks is extremely low.
The control parameters are user-specified and will vary from system to system. Furthermore, there is no exact or scientific method for establishing the value of the various parameters. The System Summary Report is a valuable tool to assist in this effort because the report lists the user-assigned value of each parameter and calculates the number of data collection samples where shutdown occurred because the limits of the particular parameter were exceeded.
This report lists all active pool sections for the reduced subsystem. The dispensed addresses are shown for each active section. The number of return hits per second is shown for short-term pool sections only. The totals for all short-term sections are listed at the end of the report. The report also lists the number of times that reorder did not occur before active buffer depletion. The System Pools Summary Report is printed as part of SYSTEM reduction only (see Figure 6).
Figure 6. System Pools Summary Report
SYSTEM POOLS SUMMARY BSS SUBSYSTEM 18 APR 09:14:33 SYSTEM PAGE 7 30 OBSERVATIONS POOL | SET REORDER DISPENSED DISPENSED STP RETURN SECTION | SIZE TIME(MIN) ADDRS/SEC ADDRS/MSG HITS/SEC -----------|-----------|-----------|-----------|-----------|-----------| | DEVA-SST | 2 0.00 0.60 1.61 0.31 DEVA-SDP | 2 0.00 0.40 1.09 N/A DEVA-LST | 2 0.00 0.57 1.52 0.00 DEVA-LDP | 1 0.00 0.00 0.00 N/A DEVA-4ST | 2 3.16 0.89 2.40 0.00 DEVA-4DP | 1 0.00 1.46 3.92 N/A DEVB-4ST | 1 0.00 0.00 0.00 0.00 DEVB-4DP | 1 0.00 0.00 0.00 N/A DEVA-4D6 | 2 25.03 1.24 3.31 N/A DEVB-4D6 | 2 21.80 1.77 4.75 N/A SHORT TERM POOL TOTALS (ALL SECTIONS) --------------------------------------- TOTAL ADDRESSES DISPENSED - 1250 TOTAL ADDRESSES RETURNED - 180 REORDER DID NOT COMPLETE BEFORE ACTIVE BUFFER DEPLETION DURING 0 INTERVALS |
This report includes the following information about the logical record cache to help you determine the most effective cache size for your installation:
The number of entries in the cache.
The amount of time, in seconds, that an entry resides in the cache before it is removed.
The number of calls to read an entry from the cache.
The number of calls that were not satisfied by the cache because the entry either was not in the cache or had timed out and was not valid.
The number of valid entries that had to be removed from the cache to make room for a new entry.
The ratio of read calls to read misses.
The number of times the cache will request the coupling facility (CF) to invalidate the cache entries for other processors for the same hash name because of an updateCacheEntry call by the application. This count will be zero for processor unique caches.
The number of times a CF notifies an application to invalidate an entry in the cache. This count will be zero for processor unique caches.
The number of times a cache entry was not added to the cache because its 16-byte name was the same as an entry already in the cache.
The following shows an example of a TPF Logical Record Cache Summary report.
Figure 7. TPF Logical Record Cache Summary Report
TPF LOGICAL RECORD CACHE SUMMARY 11 OBSERVATIONS CACHE NAME CACHE SIZE TIMEOUT READ CALLS READ MISSES CASTOUTS HIT RATIO UPDATE READ BUFFER DUPLICATE (ENTRIES) VALUE PER SECOND PER SECOND PER SECOND INVALIDATES INVALIDATES HASH (SECONDS) PER SECOND PER SECOND REFUSED IDNSHOSTADDR 10 3600 0.00 0.00 0.00 0.00% 0.00 0.00 0 IDNSHOSTNAME 10 3600 0.00 0.00 0.00 0.00% 0.00 0.00 0 MAIL_CACHES 10 3600 0.00 0.00 0.00 0.00% 0.00 0.00 0 TPF_FS_DIR 200 60 0.35 0.24 0.00 30.76% 0.00 0.00 0 TPF_FS_INODE 200 60 0.53 0.01 0.00 98.30% 0.11 0.01 0 CASH 16 3 683.22 1.20 0.00 99.82% 1.04 1.17 0 MONEY 16 3 970.67 2.72 0.00 99.71% 2.97 2.65 0 GOLDBARS 16 3 701.56 0.88 0.00 99.87% 1.57 0.86 0 INGOTS 16 3 1201.32 2.50 0.00 99.84% 1.19 0.82 0 DOLLARS 16 3 664.93 1.00 0.00 99.86% 1.29 1.03 0 ANDCENTS 16 3 769.09 1.04 0.00 99.84% 0.92 1.31 0 PENNIES 16 3 850.94 1.33 0.00 99.81% 2.51 2.15 0 CACH2 16 3 1157.65 2.19 0.00 99.86% 1.47 0.96 0 CACH4 16 3 734.97 0.97 0.00 99.70% 1.49 1.20 0 CACH6 16 3 411.13 1.21 0.00 99.84% 1.19 0.82 0 LOCALC 16 3 0.00 0.00 0.00 0.00% 0.00 0.00 0 |
Data collection for coupling facility (CF) support, CF record lock support, and logical record cache support provides data to effectively manage the performance of a CF, the CF list structures, and the CF cache structures. The following reports are provided:
See Figure 8 for an example of the Coupling Facility Usage Summary report. This report lists all the CFs defined in the processor configuration.
The Coupling Facility Usage Summary report provides:
The coupling facility (CF) name, which is a 5- to 8-character alphanumeric name that begins with an alphabetic character and is used by the TPF system to identify a CF.
The maximum storage in use, both in megabytes (MB) and as a percentage of total CF storage.
A Y in this column indicates that the amount of storage in use on this CF has changed during the data collection run. Otherwise, this column is blank.
The CF processor usage, which is calculated as B/B + W, where B represents busy time and W represents the wait time.
A Y in this column indicates that this CF was deleted and another CF with the same name was added during the data collection run. Otherwise, this column is blank.
Figure 8. Coupling Facility Usage Summary Report
COUPLING FACILITY USAGE SUMMARY 14 SEP 14.19.15 SYSTEM PAGE 8 148 OBSERVATIONS CF NAME STORAGE IN USE CHGD? UTILIZATION REPL? MB PERCENT MEAN MAX TESTCF1 5.750 24.46% 2.65% 3.23% TESTCF2 6.500 27.65% 0.01% 0.33% |
See Figure 9 for an example of the Coupling Facility Structure Summary report. This report lists all the CF structures sorted by the CF names on which the CF structures reside. This particular report shows multiple CFs and many CF structures.
The Coupling Facility Structure Summary report provides:
The name of the CF structure, organized by CF name.
The size of the CF structure both in megabytes (MB) and as a percentage of total CF storage.
The average number of CF requests issued for each second.
The average time, in microseconds, to process a request.
The average time, in microseconds, that a request waits in a queue before being started.
A Y in this column indicates that a CF structure was deleted and then reallocated during a data collection run. Otherwise, this column is blank.
The coupling facility (CF) name, which is a 5- to 8-character alphanumeric name that begins with an alphabetic character and is used by the TPF system to identify a CF.
Figure 9. Coupling Facility Structure Summary Report
COUPLING FACILITY STRUCTURE SUMMARY 14 SEP 14.19.15 11 OBSERVATIONS STRUCTURE NAME STRUCTURE SIZE REQS/SEC SERVICE TIME QUEUE TIME REPL? MB PERCENT USEC CF: FORTKNOX ANDCENTS 0.250 1.28% 2.40 9411 1520 CASH 0.250 1.28% 2.31 14067 991 DOLLARS 0.250 1.28% 2.25 20184 2251 GOLDBARS 0.250 1.28% 2.50 9282 6744 INGOTS 0.250 1.28% 5.54 11443 863 ITPFLK1_TU0001 5.000 25.64% 55.79 10884 459 ITPFLK2_TU0001 1.000 5.12% 67.65 6802 393 MONEY 0.250 1.28% 5.79 11229 553 PENNIES 0.250 1.28% 2.33 8262 742 TPF_FS_DIR 0.250 1.28% 0.10 104418 2196 CF: PIGGYBNK CACH2 0.250 0.48% 4.80 13842 4668 CACH4 0.250 0.48% 2.51 5637 2558 CACH6 0.250 0.48% 2.80 8664 689 ITPFLK1_TU0001 9.250 17.96% 23.12 8822 3060 ITPFLK2_TU0001 1.000 1.94% 23.44 8771 1133 TPF_FS_INODE 0.250 0.48% 0.22 10635 15572 |
See Figure 10 for an example of the Coupling Facility Locking Summary report. This report provides the mean and maximum values for each variable.
The Coupling Facility Locking Summary report provides:
The coupling facility (CF) name, which is a 5- to 8- character alphanumeric name that begins with an alphabetic character and is used by the TPF system to identify a CF.
The number of prime modules that are active on the CF and that use the CF for locking at the start of data collection.
A Y in this column indicates that the number of modules using this CF for locking changed during the data collection run. Otherwise, this column is blank.
The average (mean) and maximum number of lock operations performed for each CF request.
The number of lists allocated in the locking structure on this CF.
The average (mean) and maximum number of locks (list entries) for a randomly selected set of lists.
The average (mean) and maximum number of locks currently held in the CF.
The average (mean) number of locks held in the CF divided by the total number of lists allocated in the locking structure.
A Y in this column indicates that this CF was deleted and another CF with the same name was added during the data collection run. Otherwise, this column is blank.
Figure 10. Coupling Facility Locking Summary Report
COUPLING FACILITY LOCKING SUMMARY 14 SEP 14:19:15 11 OBSERVATIONS CF NAME MODULES CHGD? OPERATIONS/REQUEST LISTS LIST DEPTH LOCKS HELD LOCKS/LIST REPL? MEAN MAX MEAN MAX MEAN MAX MEAN FORTKNOX 14 1.07 10 4929 0.11 8 1223.27 1666 0.25 PIGGYBNK 9 1.18 11 8427 0.11 4 1003.45 1352 0.12 |
See Figure 11 for an example of the Coupling Facility Caching Summary report. This report provides the cache size and castout values for each CF cache.
The Coupling Facility Caching Summary report provides:
The cache name, which is a 4- to 12-character alphanumeric name that begins with an alphabetic character and is used by the TPF system to identify a CF cache.
The number of entries in the cache.
The number of valid entries that had to be removed from the cache to make room for a new entry.
The coupling facility (CF) name, which is a 5- to 8-character alphanumeric name that begins with an alphabetic character and is used by the TPF system to identify a CF.
Figure 11. Coupling Facility Caching Summary Report
COUPLING FACILITY CACHING SUMMARY 27 JUN 07:03:42 SYSTEM PAGE 12 18 OBSERVATIONS CACHE NAME CACHE SIZE CASTOUTS (ENTRIES) PER SECOND CF: CFSEARS TPF_FS_DIR 400 0.00 TPF_FS_INODE 300 0.00 |
This report includes the following information about the TPF Internet mail server to help you determine the most effective configuration for your installation:
Indicates the number of messages per second that were processed by the TPF Internet mail server. This entry shows the number of messages that were received, sent to local and remote clients, and not delivered (bounced).
Indicates the number of characters per message that were received and sent by the TPF Internet mail server.
Indicates the amount of mail (in blocks) in the active and deferred queues that is currently waiting to be delivered. Each block contains from 1 to 50 pieces of mail.
Indicates the following for the local, remote, and deferred delivery managers:
The number of ECBs that are currently sending mail at the same time.
The maximum number of ECBs that are allowed to send mail at the same time.
If the queue length of the active queue is too large for your environment or if the queue length increases over time, there are not enough delivery managers defined for the local or remote active queue. Similarly, if the queue length of the deferred queue is too large or increases, there are not enough delivery managers defined for the deferred queue. The number of delivery managers is defined in the TPF configuration file (/etc/tpf_mail.conf). See TPF Transmission Control Protocol/Internet Protocol for more information about the TPF configuration file.
The following shows an example of a TPF Internet mail server summary report.
Figure 12. TPF Internet Mail Server Summary Report
TPF INTERNET MAIL SERVER SUMMARY 16 FEB 10:24:36 SYSTEM PAGE 11 300 OBSERVATIONS IN OUT BOUNCED LOCAL REMOTE MESSAGES PER SECOND 4.77 0.63 0.00 0.09 CHARACTERS PER MESSAGE 602 0 ACTIVE DEFERRED QUEUE LENGTH (BLOCKS) 80.62 176.12 DELIVERY MANAGERS LOCAL REMOTE DEFERRED MEAN NUMBER ACTIVE 9.37 7.62 0.00 MAXIMUM ALLOWED 10.00 10.00 10.00 |
This report includes information about the number of TCP/IP weighted input messages for each TCP/IP native stack application for which there is activity. The TCP/IP weighted message by application report provides the following information:
The name of the application. The application must be defined in the TCP/IP network services database. If an application is not defined in the database, the number of messages is shown in the OTHER category. See TPF Transmission Control Protocol/Internet Protocol for more information about defining applications in the TCP/IP network services database.
The port associated with this application.
The weighting factor used when counting the input messages for this application. This weighting factor can be defined for each application in the TCP/IP network services database by specifying the weight parameter. If a weighting factor is not defined for the application, this column contains asterisks (***). See TPF Transmission Control Protocol/Internet Protocol for more information about defining applications in the TCP/IP network services database and how message counts are incremented for TCP/IP applications.
The number of weighted messages received by this application.
The number of weighted messages per second received by this application.
The percentage of the total number of TCP/IP messages received in the TPF system.
The cumulative percentage of the total number of TCP/IP messages received in the TPF system.
The information in this report is sorted in descending order by activity; that is, the application with the highest activity is shown at the top of the report.
The following shows an example of a TCP/IP weighted input messages by application report.
Figure 13. TCP/IP Weighted Input Messages by Application Report
TCP/IP WEIGHTED MESSAGES BY APPLICATION 04 FEB 14:44:57 SYSTEM PAGE 9 APPLICATION PORT WEIGHT WEIGHTED WEIGHTED PERCENT CUMULATIVE MESSAGES MSGS/SEC OF TOTAL PERCENT TEST-9981 9981 *** 278463 153.36 17.07% 17.07% TEST-9980 9980 *** 278304 153.27 17.06% 34.14% TEST-9982 9982 *** 278138 153.18 17.05% 51.20% TEST-9984 9984 *** 278041 153.12 17.05% 68.25% TEST-9983 9983 *** 258880 142.57 15.87% 84.13% TEST-9985 9985 *** 258382 142.30 15.84% 99.97% OTHER *** 169 0.09 0.01% 99.98% RIP 520 50 65 0.04 0.00% 99.99% FTP-DATA 20 100 58 0.03 0.00% 99.99% TFTP 69 100 42 0.02 0.00% 100.00% TOTAL 1630542 897.98 100.00% 100.00% |
The number of frames held by exiting ECBs is reported in histogram form.
Figure 14. ECB Frame Usage Summary Report
TPF ECB FRAME USAGE SUMMARY REPORT SYSTEM WIDE 27 FEB 14:18:27 SYSTEM PAGE 7 MEAN TOTAL FRAMES USED DURING ECB LIFETIME 1 FRAMES CLASS UPPER FREQUENCY PERCENT FREQUENCY DIAGRAM (SCALE = 968/1) LIMIT OBSERVED OF TOTAL 0 77362 58.58% |******************************************************************************** 1 428 0.32% |* 2 158 0.12% |* 3 19900 15.07% |********************* 4 34022 25.76% |************************************ 5 41 0.03% |* 6 40 0.03% |* 7 19 0.01% |* 8 0 0.00% | 9 41 0.03% |* 10 0 0.00% | 11 0 0.00% | 12 0 0.00% | 13 0 0.00% | 14 0 0.00% | 15 0 0.00% | 16 0 0.00% | 17 0 0.00% | 18 0 0.00% | 19 0 0.00% | 20 0 0.00% | 25 20 0.02% |* 30 20 0.02% |* 35 0 0.00% | 40 1 0.00% |* 45 0 0.00% | 50 0 0.00% | 60 0 0.00% | 70 8 0.01% |* 80 0 0.00% | 90 0 0.00% | 100 0 0.00% | 120 0 0.00% | 140 0 0.00% | 160 0 0.00% | 180 0 0.00% | 200 0 0.00% | 220 0 0.00% | 240 0 0.00% | > 240 0 0.00% | |
The number of heap frames held by exiting ECBs is reported in histogram form.
Figure 15. Heap Area Usage Report
TPF ECB HEAP AREA USAGE SUMMARY REPORT SYSTEM WIDE 27 FEB 14:18:27 SYSTEM PAGE 8 MEAN FRAMES USED FOR HEAP STORAGE DURING ECB LIFETIME 0 FRAMES MAXIMUM FRAMES USED FOR HEAP STORAGE BY AN ECB 58 FRAMES CLASS UPPER FREQUENCY PERCENT FREQUENCY DIAGRAM (SCALE = 1650/1) LIMIT OBSERVED OF TOTAL 0 131970 99.93% |******************************************************************************** 1 82 0.06% |* 2 0 0.00% | 3 0 0.00% | 4 0 0.00% | 5 0 0.00% | 6 0 0.00% | 7 0 0.00% | 8 0 0.00% | 9 0 0.00% | 10 0 0.00% | 11 0 0.00% | 12 0 0.00% | 13 0 0.00% | 14 0 0.00% | 15 0 0.00% | 16 0 0.00% | 17 0 0.00% | 18 0 0.00% | 19 0 0.00% | 20 0 0.00% | 25 0 0.00% | 30 0 0.00% | 35 0 0.00% | 40 0 0.00% | 45 0 0.00% | 50 0 0.00% | 60 8 0.01% |* 70 0 0.00% | 80 0 0.00% | 90 0 0.00% | 100 0 0.00% | 120 0 0.00% | 140 0 0.00% | 160 0 0.00% | 180 0 0.00% | 200 0 0.00% | 220 0 0.00% | 240 0 0.00% | > 240 0 0.00% | |
This report contains static Multi-Processor Interconnect Facility (MPIF) information. It can be used to determine the general MPIF environment specifications. MPIF-related reports are omitted when MPIF is not active.
Figure 16. MPIF Configuration Report
MPIF CONFIGURATION SYSTEM WIDE 27 FEB 14:18:27 SYSTEM PAGE 9 CRITICAL ACTIVE ECB BLOCKS : 0 NUMBER OF PROCESSORS : 10 NUMBER OF GLOBAL USERS : 100 NUMBER OF RESIDENT USERS : 24 NUMBER OF CONNECTIONS : 90 NUMBER OF PATHS : 23 NUMBER OF PATH ACTIVATION NOTIFICATION : 90 NUMBER OF DIRECTORY NOTIFICATION : 90 NUMBER OF CLASSES : 3 BUFFER SIZE : 2265088 INTERFACE VERSION NUMBER : 3 NAME OF THE SYSTEM : CPUB.JM CONNECTION TIMEOUT INTERVAL : 80 1ST LEVEL PATH TIMEOUT INTERVAL : 81 2ND LEVEL PATH TIMEOUT INTERVAL : 82 PDT OUTPUT QUEUE DEPTH : 10 NUMBER OF LINKS BETWEEN PROCESSORS : 10 |
This report is generated when MPIF IPC is active. The report gives information about path activity between the origin processor and other processors, and includes mean values per second for the following:
Figure 17. Interprocessor Communication MPIF Report
INTERPROCESSOR COMMUNICATION MPIF SUMMARY ORIGIN PROCESSOR TPF CPU-ID = B DEST TPF TOT SIPCC TOT SIPCC TOT SIPCC XMIT FAIL XMIT FAIL CPU-ID ITEMS SENT RECEIVED RETURN RETURN NO RETURN B 0.00 0.00 0.00 0.00 0.00 C 0.00 0.00 0.00 0.00 0.00 D 0.00 0.00 0.00 0.00 0.00 E 0.00 0.00 0.00 0.00 0.00 Z 0.00 0.00 0.00 0.00 0.00 0 0.00 0.00 0.00 0.00 0.00 NOTE: COUNTS ARE FROM ORIGIN CPU VIEW POINT IE: SENT TO DESTINATION CPU OR RECEIVED FROM DESTINATION CPU NOTE: ALL VALUES SHOWN ARE TOTALS PER SECOND |
Performance data for the MPIF paths are contained in the report. This data can be used to detect if a bottleneck exists on a particular path and help to determine the cause. The optional plot reports can help pinpoint heavy utilization periods.
The report is printed in order of path class, and in addition to class, path, and device names, it contains: message rate (messages per second), the average message size, the reads and writes per second, the number of requests on the pending queue, and the number of queue overruns. See Figure 18 for the format of the report.
Figure 18. MPIF Path Activity Report
MPIF PATH ACTIVITY REPORT 27 FEB 14:18:27 SYSTEM PAGE 10 CTCNAME PATHNAME CL MSGRATE MSGSIZE READS WRITES QUEUED OVERRUNS (/SEC) (AVG) (/SEC) (/SEC) (AVG) (TOTAL) CPUB.A1 A 0.00 0.00 0.00 0.00 0 0 CPUC.A1 A 0.00 0.00 0.00 0.00 0 0 CPUD.A1 A 0.00 0.00 0.00 0.00 0 0 CPUE.A1 A 0.00 0.00 0.00 0.00 0 0 CPUZ.A1 A 0.00 0.00 0.00 0.00 0 0 CPU0.A1 A 0.00 0.00 0.00 0.00 0 0 CPU1.A1 A 0.00 0.00 0.00 0.00 0 0 CPU2.A1 A 0.00 0.00 0.00 0.00 0 0 CPUB.B1 B 0.00 0.00 0.00 0.00 0 0 CPUC.B1 B 0.00 0.00 0.00 0.00 0 0 CPUD.B1 B 0.00 0.00 0.00 0.00 0 0 CPUE.B1 B 0.00 0.00 0.00 0.00 0 0 CPUZ.B1 B 0.00 0.00 0.00 0.00 0 0 CPU0.B1 B 0.00 0.00 0.00 0.00 0 0 CPU1.B1 B 0.00 0.00 0.00 0.00 0 0 CPU2.B1 B 0.00 0.00 0.00 0.00 0 0 CPUC.C1 C 0.00 0.00 0.00 0.00 0 0 CPUD.C1 C 0.00 0.00 0.00 0.00 0 0 CPUE.C1 C 0.00 0.00 0.00 0.00 0 0 CPUZ.C1 C 0.00 0.00 0.00 0.00 0 0 CPU0.C1 C 0.00 0.00 0.00 0.00 0 0 CPU1.C1 C 0.00 0.00 0.00 0.00 0 0 CPU2.C1 C 0.00 0.00 0.00 0.00 0 0 |
Frequency distribution reports can be optioned for all the parameters in the system collector (see Figure 19). Actually, the distribution reports for almost all collected parameters can be obtained by placing the DISTRIBUTION keyword in the option field of any option card.
Figure 19. Frequency Distribution Report
These distribution reports are used to investigate any unusual data such as extreme maximum or minimum values found in the summary. Wide variances indicate that the processing flow through the system is not smooth. Examination of the class limits and observed frequencies can verify that the system is experiencing wide swings in either input or utilization of one or more of its resources. When such a situation occurs, use caution when comparing one variable to another in order to distinguish cause from effect. Peaks occurring in one variable usually impact some other resource later in the processing cycle. Note that these reports are concerned with frequency distribution only; no chronology of samples is set up.
To distinguish the cause from effect mentioned previously, a chronological listing is necessary. In addition to the frequency distributions produced, the plot reports show each variable chronologically by interval over the life of the collection (see Figure 20). A separate page is produced for each 100 intervals of the collection period. The clock time associated with the start of each interval is shown along the abscissa.
Variables may now be compared. For example, a very high working storage utilization might have caused polling to be suspended; a high input rate and a long input list appear after polling is resumed. Depending on the order of occurrence, these same variables might indicate an entirely different situation. An extreme peak in high-speed messages can result in a long input list and high core utilization. Any regularity in this type of peaking suggests an adjustment of system parameters that control polling frequency. Messages are allowed to queue in the terminal interchange buffers before being polled into the system.
The proper collection mode, period, and interval must be chosen for the type of analysis suggested previously. Fluctuations may be hidden completely by the smoothing effect of long intervals.
The plot reports are available for all the same parameters as the distribution reports.
The limitations imposed on the reduction by the PL/I pre-compiler options appear near the end of the reduction report. A sample of this page is shown in Figure 21. These limits are set by you to match the online system or to restrict the types of data to be reduced. For instance, two versions of the data reduction package could be maintained in the system library, one that handles only system collector data, and the other that reduces data from all collectors. The system collector version would be used more often and would run in a smaller memory partition.
Figure 21. Data Reduction Limitations Report