Performance Manager Overview

Performance Manager collects data using a variety of collectors.

  • CPU and JOBS data is obtained from the STCPUR collector,

  • Communications data (X25, conventional TCP/IP, parallel TCP/IP, TCPIPv6 and CIP) comes from the STCOMM collector,

  • Measure entities are provided by MEASURE. MEASURE is HP software that provides services to collect performance information about system resources on HPE NonStop servers.

Because such a wide variety of information is collected from different sources the information is broken down into two parts:


There is one STCPUR collector per CPU that is responsible for gathering data for the CPU and JOBS records. This information is collected directly from pointer blocks at the Guardian level.

The STCOMM collector uses the Subsystem Programmatic Interface (SPI) to request status and statistics from the supported communications subsystems (X25, conventional TCP/IP, parallel TCP/IP, TCPIPv6 and CIP).

The Network Router (irnetrtr) combines the information from the collectors for delivery to the requesting processes (Thresholds, Databases, etc.).

Performance Manager Data Collection (Non Measure)


When a data request for MEASURE records is made, the STMESMAN collector creates the process STMEAS which starts a Measure collection for the required records at the requested refresh interval.

This first request (1) is shown in the top left corner of the diagram below. If an additional request (2) at a different refresh interval is made, the monitor requests an additional MEASURE collection (b).

The third request (3) is for the same interval as an existing request, so no additional MEASURE collection is started. The existing collection is updated to include the newly requested records.

Performance Manager Data Collection (MEASURE)

There are two files for each data collection, e.g. MEAS0001 and MEAS0002. STMEAS switches between them per interval so that one can be read while the other is being written to.

Monitoring the STMEAS Processes

The STMESMAN collector starts and then monitors the status of STMEAS processes. If an STMEAS process stops, STMESMAN will assess the reason for the stoppage based on the system message received.

  • If the STMEAS process goes down due to a ‘stop’ command then it is considered to be ‘orderly’ or ‘intentional’ and the process will not be restarted.
  • If an STMEAS process goes down due to an 'abend' or CPU down condition, then the process is restarted. If the STMEAS abends a second time it will not be restarted because the problem is assumed to be terminal and this avoids the expense of additional process creation. This check for a previous 'abend' is reset at the start of new requests, and is only in place whilst a request is active and unchanged.

If there is a SET CPU (STMEAS, X)  in PROGNOSIS Configuration and CPU X goes down then STMESMAN will restart STMEAS on another CPU.

Provide feedback on this article