For the DISK, MODES, SCS, and STATES classes, you can optionally express all statistics as percentages.
In the PROCESSES class, MONITOR displays descriptive information, level information, and counters that increase over time.
MONITOR collects system performance data by class and produces three forms of optional output, depending on the qualifier you specify:
Qualifier | Description |
---|---|
/DISPLAY | Produces output in the form of ASCII screen images, which are written at a frequency governed by the /VIEWING_TIME qualifier. |
/RECORD | Produces a binary recording file containing data collected for requested classes; one record for each class is written per interval. |
/SUMMARY | Produces an ASCII file containing summary statistics for all requested classes over the duration of the MONITOR request. |
If you specify /INPUT with any of these qualifiers, MONITOR collects performance data from one or more previously created recording files; otherwise, data is collected from counters and data structures on the running system.
You use the /BEGINNING and /ENDING qualifiers to specify, respectively, when you want a MONITOR request to begin and end.
Using the /DISPLAY Qualifier
Information collected by MONITOR is normally displayed as ASCII screen images. You can use the optional /DISPLAY qualifier to specify a disk file to contain the information. If you omit the file specification, output is directed to SYS$OUTPUT.
Note
Be careful when you use the /DISPLAY qualifier. Because MONITOR enters display information into the file continuously, its size can grow very quickly.
See the OpenVMS System Management Utilities Reference Manual for a discussion of the /DISPLAY qualifier.
Using the /RECORD Qualifier
When you use the /RECORD qualifier, all data pertaining to the class is recorded, even if you are concurrently displaying only a single statistic or a single item of a component statistics class. The file is created when a MONITOR request is initiated and closed when a request terminates. You can use the resulting file as a source file for later requests to format and display the data on a terminal, to create a summary file, or to create a new recording file with different characteristics.
To invoke the Monitor utility, enter the following DCL command:
$ MONITOR
MONITOR then displays the following prompt:
MONITOR>
In response to the prompt, you can enter any of the MONITOR commands, which are described in OpenVMS System Management Utilities Reference Manual. The most frequently used MONITOR command, however, specifies a class name.
Example
MONITOR> MONITOR PAGE
In this example, you specify the PAGE class name in the MONITOR command to monitor page management statistics.
You can also use the MONITOR command from DCL command level.
How to Override or Terminate a MONITOR Request
Generally, each MONITOR request runs until the time specified or implied by the /ENDING qualifier. However, to override or terminate a MONITOR request, you can press one of the following:
Keys | Description |
---|---|
Ctrl/W |
Temporarily overrides a /VIEWING_TIME value and generates a new display
immediately following the current one. This feature is useful when a
broadcast message overwrites the MONITOR display area.
You can also use Ctrl/W in conjunction with a large /VIEWING_TIME value to generate display events on demand. |
Ctrl/C | Terminates the current request without exiting from the utility. You can then initiate a new request or enter any MONITOR command at the MONITOR> prompt. |
Ctrl/Z | Terminates the current request and exits from MONITOR. |
Use the live display monitoring mode of operation when you want to examine the activity of a running system, either on a routine basis or as part of an installation checkout, tuning, or troubleshooting exercise. The system does not keep a historical record of output. The following examples show how to use the live display monitoring mode.
Examples
$ MONITOR PROCESSES/TOPCPU
OpenVMS Monitor Utility TOP CPU TIME PROCESSES on node BOMBAY 20-JAN-1996 10:06:49 0 25 50 75 100 + - - - - + - - - - + - - - - + - - - - -+ 07E00181 CAFARET 100 **************************************** | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | + - - - - + - - - - + - - - - + - - - - -+
$ SHOW PROCESS/CONTINUOUS/ID=07E00181
. . . $1$DUA1:[SYS1D.SYSCOMMON.][SYSEXE]RODAN.EXE
$ MONITOR/DISPLAY=PROCESSES.LOG PROCESSES
Caution
Because data is continuously added to the display file, be careful that the file does not grow too large.
$ MY_CLASSES :== - _$ "DECNET+FCP+IO+LOCK+MODES+PAGE+PROCESSES+STATES" $ MONITOR/NODE=(CURLEY,LARRY)/INTERVAL=20/VIEWING_TIME=8 'MY_CLASSES'
Use live recording to capture MONITOR data for future use. Possible uses include the following:
Caution
Because data is continuously added to the recording file, be careful that the file does not grow too large.
The following example shows how to use the live recording mode of operation.
Example
$ MONITOR/NODE=(LARRY,MOE)/NODISPLAY/RECORD MODES+STATES
The command in this example records data on the time spent in each processor mode and on the number of processes in each scheduler state for nodes LARRY and MOE. The command does not display this information.
Use the concurrent display and recording mode of operation when you want to both retain performance data and watch as it is being collected. Because MONITOR allows shared read access to the recording file, a separate display process can play back the recording file as it is being written by another process.
The following examples show how to use the concurrent display and recording mode of operation. The first example both collects and records data in the same command. The second and third examples show how you can perform concurrent recording and display using two separate processes: the process in the second example performs recording; the process in the third example plays back the file to obtain a summary.
Examples
$ MONITOR/RECORD FCP/AVERAGE,FILE_SYSTEM_CACHE/MINIMUM
$ MONITOR/RECORD=SYS$MANAGER:ARCHIVE.DAT - _$ /INTERVAL=300/NODISPLAY ALL_CLASSES
$ MONITOR/INPUT=SYS$MANAGER:ARCHIVE.DAT: - _$ /NODISPLAY/SUMMARY/BEGINNING="-1" PAGE,IO
Use playback of a recording file to obtain terminal output and summary reports of all collected data or a subset of it. You can make a subset of data according to class, node, or time segment. For example, if you collect several classes of data for an entire day, you can examine or summarize the data on one or more classes during any time period in that day.
You can also display or summarize data with a different interval than the one at which it was recorded. You control the actual amount of time between displays of screen images with the /VIEWING_TIME qualifier. The following examples show how to use the playback mode of operation.
Examples
$ MONITOR/RECORD/INTERVAL=5 IO . . . $ MONITOR/INPUT IO
$ MONITOR/RECORD/NODISPLAY - _$ /BEGINNING=08:00:00 - _$ /ENDING=16:00:00 - _$ /INTERVAL=120 DISK . . . $ MONITOR/INPUT/DISPLAY=HOURLY.LOG/INTERVAL=3600 DISK
Note
The current statistic in HOURLY.LOG shows the current data in terms of the original collection interval of 120 seconds, not the new collection interval of 3600 seconds.
$ MONITOR/INPUT/NODISPLAY/SUMMARY=DAILY.LOG DISK
OpenVMS Monitor Utility DISK I/O STATISTICS on node TLC From: 25-JAN-1996 08:00:00 SUMMARY To: 25-JAN-1996 16:00:00 I/O Operation Rate CUR AVE MIN MAX DSA0: SYSTEM_0 0.53 1.50 0.40 3.88 DSA1: SYSTEM_1 0.00 0.39 0.00 8.38 DSA4: WORK_0 0.00 0.11 0.00 1.29 DSA5: WORK_1 0.03 0.87 0.00 5.95 DSA6: WORK_2 0.03 0.25 0.00 2.69 DSA7: WORK_3 0.04 0.97 0.00 20.33 DSA17: TOM_DISK 0.00 0.04 0.00 0.80 DSA23: MKC 0.00 0.00 0.00 0.13 $4$DUA0: (RABBIT) SYSTEM_0 0.20 0.65 0.17 1.97 $4$DUA2: (RABBIT) SYSTEM_0 0.20 0.65 0.17 1.97 $4$DUA3: (RABBIT) SYSTEM_1 0.00 0.14 0.00 2.49 PLAYBACK SUMMARIZING
If suitably privileged, you can collect MONITOR data from any system to which your system has a DECnet connection. You can then display the data live on your local system. To do so, follow these steps:
$ ! $ ! * Enable MONITOR remote playback * $ ! $ MONITOR /NODISPLAY/RECORD=SYS$NET ALL_CLASSES
DEFINE remotenodename_mon node::task=monitor
MONITOR/INPUT=remotenodename_mon classnames
You can also place MONITOR.COM files in directories other than the default DECnet directory and use access control strings or proxy accounts to invoke these command files remotely.
When you invoke MONITOR on your local system, a process is created on the remote system that executes the MONITOR.COM command file. The remote system therefore experiences some associated CPU and DECnet overhead. You can regulate the overhead in the MONITOR.COM file by using the /INTERVAL qualifier and the list of class names.
Section 18.8.10 describes remote monitoring in a mixed-version cluster system.
Rerecording is a combination of playback and recording. You can use it for data reduction of recording files. When you play back an existing recording file, all MONITOR options are available to you; thus, you can choose to record a subset of the recorded classes and a subset of the recorded time segment and a larger interval value.
All these techniques produce a new, smaller recording file at the expense of some of the recorded data. A larger interval value reduces the volume of the collected data, so displays and summary output produced from the newer recorded file will be less precise. Note that average rate values are not affected in this case, but average level values are less precise (since the sample size is reduced), as are maximum and minimum values. The following example shows how to use the rerecording mode of operation:
Example
$ SUBMIT MONREC.COM
MONREC.COM contains the following commands:
$ MONITOR/NODISPLAY/RECORD/INTERVAL=60 /BEGINNING=8:00/ENDING=16:00 DECNET,LOCK $ MONITOR/INPUT/NODISPLAY/RECORD DECNET
The first command runs in a batch job, recording DECnet and lock management data once every minute between the hours of 8 A.M. and 4 P.M.. The second command, which is issued after the first command completes, rerecords the data by creating a new version of the MONITOR.DAT file, containing only the DECnet data.
You can develop a database of performance information for your system by running MONITOR continuously as a background process. This section contains examples of procedures that you, as cluster manager, might use to create multifile clusterwide summaries.
You can adapt the command procedures to suit conditions at your site. Note that you must define the logical names SYS$MONITOR and MON$ARCHIVE in SYSTARTUP.COM before executing any of the command files.
The directory with the logical name SYS$EXAMPLES includes three command procedures that you can use to establish the database. Instructions for installing and running the procedures are in the comments at the beginning of each procedure. Table 18-9 contains a brief summary of these procedures.
Procedure | Description |
---|---|
MONITOR.COM | Creates a summary file from the recording file of the previous boot, and then begins recording for this boot. The recording interval is 10 minutes. |
MONSUM.COM | Generates two clusterwide multifile summary reports that are mailed to the system manager: one report is for the previous 24 hours, and the other is for the previous day's prime-time period (9 A.M. to 6 P.M.). The procedure resubmits itself to run each day at midnight. |
SUBMON.COM | Starts MONITOR.COM as a detached process. Invoke SUBMON.COM from the site-specific startup command procedure. |
While MONITOR records data continuously, a summary report can cover any finite time segment. The MONSUM.COM command procedure, which is executed every midnight, produces and mails the two multifile summary reports described in Table 18-9. Because these reports are not saved as files, to keep them, you must either extract them from your mail file or alter the MONSUM.COM command procedure to save them.
The procedure in Example 18-7 archives the recording file and summary file from the previous boot and initiates continuous recording for the current boot. (Note that this procedure does not purge recording files.)
Example 18-7 MONITOR.COM Procedure
$ SET VERIFY $ ! $ ! MONITOR.COM $ ! $ ! This command file is to be placed in a cluster-accessible directory $ ! called SYS$MONITOR and submitted at system startup time as a detached $ ! process via SUBMON.COM. For each node, MONITOR.COM creates, in $ ! SYS$MONITOR, a MONITOR recording file that is updated throughout the $ ! life of the boot. It also creates, in MON$ARCHIVE, a summary file from $ ! the recording file of the previous boot, along with a copy of that $ ! recording file. Include logical name definitions for both cluster- $ ! accessible directories, SYS$MONITOR and MON$ARCHIVE, in SYSTARTUP.COM. $ ! $ SET DEF SYS$MONITOR $ SET NOON $ PURGE MONITOR.LOG/KEEP:2 $ ! $ ! Compute executing node name and recording and summary file names $ ! (incorporating node name and date). $ ! $ NODE = F$GETSYI("NODENAME") $ SEP = "" $ IF NODE .NES. "" THEN SEP = "_" $ DAY = F$EXTRACT (0,2,F$TIME()) $ IF F$EXTRACT(0,1,DAY) .EQS. " " THEN DAY = F$EXTRACT(1,1,DAY) $ MONTH = F$EXTRACT(3,3,F$TIME()) $ ARCHFILNAM = "MON$ARCHIVE:"+NODE+SEP+"MON"+DAY+MONTH $ RECFIL = NODE+SEP+"MON.DAT" $ SUMFIL = ARCHFILNAM+".SUM" $ ! $ ! Check for existence of recording file from previous boot and skip $ ! summary if not present. $ ! $ OPEN/READ/ERROR=NORECFIL RECORDING 'RECFIL' $ CLOSE RECORDING $ ! $ ! $ ! Generate summary file from previous boot. $ ! $ MONITOR /INPUT='RECFIL' /NODISPLAY /SUMMARY='SUMFIL' - $ ALL_CLASSES+MODE/ALL+STATES/ALL+SCS/ITEM=ALL+SYSTEM/ALL+DISK/ITEM=ALL $ ! $ ! $ ! Compute subject string and mail summary file to cluster manager. $ ! $ ! $ A=""" $ B=" MONITOR Summary " $ SUB = A+NODE+B+F$TIME()+A $ MAIL/SUBJECT='SUB' 'SUMFIL' CLUSTER_MANAGER $ ! $ ! $ ! Archive recording file and delete it from SYS$MONITOR. $ ! $ COPY 'RECFIL' 'ARCHFILNAM'.DAT $ DELETE 'RECFIL';* $ ! $ NORECFIL: $ SET PROCESS/PRIORITY=15 $ ! $ ! $ ! Begin recording for this boot. The specified /INTERVAL value is $ ! adequate for long-term summaries; you might need a smaller value $ ! to get reasonable "semi-live" playback summaries (at the expense $ ! of more disk space for the recording file). $ ! $ MONITOR /INTERVAL=300 /NODISPLAY /RECORD='RECFIL' ALL_CLASSES $ ! $ ! $ ! End of MONITOR.COM $ !
The procedure in Example 18-8 submits MONITOR.COM as a detached process from SYSTARTUP.COM to initiate continuous recording for the current boot.
Example 18-8 SUBMON.COM Procedure
$ SET VERIFY $ ! $ ! SUBMON.COM $ ! $ ! This command file is to be placed in a cluster-accessible directory $ ! called SYS$MONITOR. At system startup time, for each node, it is $ ! executed by SYSTARTUP.COM, following logical name definitions for $ ! the cluster-accessible directories SYS$MONITOR and MON$ARCHIVE. $ ! $ ! $ ! Submit detached MONITOR process to do continuous recording. $ ! $ ! $ RUN SYS$SYSTEM:LOGINOUT.EXE - /UIC=[1,4] - /INPUT=SYS$MONITOR:MONITOR.COM - /OUTPUT=SYS$MONITOR:MONITOR.LOG - /ERROR=SYS$MONITOR:MONITOR.LOG - /PROCESS_NAME="Monitor" - /WORKING_SET=512 - /MAXIMUM_WORKING_SET=512 - /EXTENT=512/NOSWAPPING $ ! $ ! $ ! End of SUBMON.COM $ !
The procedure in Example 18-9 produces daily and prime-time clusterwide summaries.
Example 18-9 MONSUM.COM Procedure
$ SET VERIFY $ ! $ ! MONSUM.COM $ ! $ ! This command file is to be placed in a cluster-accessible directory $ ! called SYS$MONITOR and executed at the convenience of the cluster $ ! manager. The file generates both 24-hour and "prime time" cluster $ ! summaries and resubmits itself to run each day at midnight. $ ! $ SET DEF SYS$MONITOR $ SET NOON $ ! $ ! Compute file specification for MONSUM.COM and resubmit the file. $ ! $ FILE = F$ENVIRONMENT("PROCEDURE") $ FILE = F$PARSE(FILE,,,"DEVICE")+F$PARSE(FILE,,,"DIRECTORY")+F$PARSE(FILE,,,"NAME") $ SUBMIT 'FILE' /AFTER=TOMORROW /NOPRINT $ ! $ ! Generate 24-hour cluster summary. $ ! $ ! $ MONITOR/INPUT=(SYS$MONITOR:*MON*.DAT;*,MON$ARCHIVE:*MON*.DAT;*) - /NODISPLAY/SUMMARY=MONSUM.SUM - ALL_CLASSES+DISK/ITEM=ALL+SCS/ITEM=ALL- /BEGIN="YESTERDAY+0:0:0.00" /END="TODAY+0:0:0.00" /BY_NODE $ ! $ ! $ ! Mail 24-hour summary file to cluster manager and delete the file from $ ! SYS$MONITOR. $ ! $ ! $ MAIL/SUBJECT="Daily Monitor Clusterwide Summary" MONSUM.SUM CLUSTER_MANAGER $ DELETE MONSUM.SUM;* $ ! $ ! Generate prime-time cluster summary. $ ! $ ! $ MONITOR/INPUT=(SYS$MONITOR:*MON*.DAT;*,MON$ARCHIVE:*MON*.DAT;*) - /NODISPLAY/SUMMARY=MONSUM.SUM - ALL_CLASSES+DISK/ITEM=ALL+SCS/ITEM=ALL- /BEGIN="YESTERDAY+9:0:0.00" /END="YESTERDAY+18:0:0.00" /BY_NODE $ ! $ ! $ ! Mail prime-time summary file to cluster manager and delete the file $ ! from SYS$MONITOR. $ ! $ ! $ MAIL/SUBJECT="Prime-Time Monitor Clusterwide Summary" MONSUM.SUM CLUSTER_MANAGER $ DELETE MONSUM.SUM;* $ ! $ ! End of MONSUM.COM $ !
Because summary data might be extensive, Digital recommends that you print out summary files.
MONITOR is capable of using both TCP/IP and DECnet as a transport mechanism. Beginning with OpenVMS Version 7.0, to use TCP/IP, you must start the TCP/IP server by issuing the following command inside SYS$STARTUP:SYSTARTUP_VMS.COM:
$ @SYS$STARTUP:VPM$STARTUP.COM
DECnet continues to work as in the past: a network object is created at the time of the request.
Remote Monitoring in a Mixed-Version OpenVMS Cluster
System
You can monitor any node in an OpenVMS Cluster system either by issuing the MONITOR CLUSTER command or by adding the /NODE qualifier to any interactive MONITOR request.
6017P060.HTM OSSG Documentation 22-NOV-1996 14:22:45.17
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.