gtps3m0f | System Performance and Measurement Reference |
Run data collection every day during the peak hour to provide a history file of key system parameters such as milliseconds per message, file accesses per message, working storage usage per message, enters per message, message rate, and message length. Any changes in system configuration, programs, or storage allocation should be carefully documented and dated so that the performance aspects of the system obtained from data collection can be correlated to these changes. This information plus the history and trend of function activity (for example, passengers boarded) can be used very effectively to predict the need for additional memory, channels, files, lines, terminals, or CPU capacity.
The daily peak hour runs should use all collectors in the sampling mode. To find the peak hour each day will involve a more extensive use of data collection initially. The system collector can be run in sampling mode during each hour of the prime shift to observe the hourly trend. The 60-minute period during which the highest mean high-speed input message rate occurs is defined as the peak hour. In most systems a double peak occurs (mid-morning and mid-afternoon). It may be necessary to track the double-peak. In such cases, alternate the running of sampling mode (all collectors) with continuous mode (system collector), for each peak, to reduce the amount of data collected.
The message format required to start and stop data collection in sampling and continuous mode can be found under system performance in TPF Operations.
In a system that is loosely coupled, where all processors share a common set of files, you can run data collection on each processor nonconcurrently or concurrently. If run nonconcurrently, data is collected on each processor one after the other. If run concurrently, it is unnecessary, and even undesirable, for more than one processor to collect complexwide data from the storage controls. The ZMEAS command has a parameter for specifying which processor is to collect exclusively complexwide data.
Data collection retrieves the high watermark value at the start and end of each data collection episode. The value retrieved at the end of the episode is used as the episodic high watermark.
When data collection is run concurrently and when CFLF is supported, you should use the ZMEAS x command, where x is the CPU ID on which data is to be collected. The use of this parameter ensures that data collection has collected valid high watermark values. Data collection is activated in the basic subsystem and collects information about all subsystems in a multiple database function (MDBF) environment.
The option card formats used to specify which reduction reports are desired can be found under system performance in TPF Operations.
The initial analysis of any RTC tape should always start with summary reports only. The summary reports will provide all the key performance data required for history and trend analysis. When investigating a problem area, the more detailed plot and distribution reports or the specialized reports of the file and message reduction programs can be used. The plot reports showing the value of each parameter sample in chronological order can be very effective for cross-correlation of the cause and effect relationship between parameters. The file reports such as cylinder analysis and record ID analysis can be used to investigate overloading conditions on the files. The message reports such as line summary, terminal activity, logical unit activity, and message stream can be used to investigate overloading of the high-speed lines, effectiveness, and system response time.
In a loosely coupled environment, data reductions are performed for each processor. The results are similar to those obtained in a single processor environment. The primary shared resource is the file subsystem.