IBM: Performance and Monitor Data Collection

z/VM >

Performance and Monitor Data Collection

Some useful CP commands

INDICATE QUEUES EXP if scheduler related (get a couple of these).: useful for looking at scheduler related problems and snapshot of what users are waiting on. Since this is a snapshot, it is often most useful to capture repeated invocations.
QUERY FRAMES: useful for storage related problems
INDICATE I/O: See what users are waiting for what I/O. Can be great to spot a volume for which minidisk cache or CU cache were mistakenly turned off.
QUERY NSS MAP: use this to insure segments are being used in storage related problems.

Monitor Data Collection

The exact data we collect may differ slightly from problem to problem, but the following sections give insight into what data to collect and how to go about doing that.

Quick Cheat Sheet

Create DCSS. If a DCSS does not already exist, you will need to create one. Issue the CP QUERY NSS NAME MONDCSS to check for the existence of a DCSS for monitor. If it does not exist, then the following CP privileged commands can be used to create a 10 meg DCSS starting at 35 meg. This is big enough for typical systems.
```
     CP DEFSEG MONDCSS 2300-2FFF SC RSTD
     CP SAVESEG MONDCSS
```
Set up userid. If you don't currently run monitor, you will need to set up a userid to run the MONWRITE utility. The following must be in the user entry.
```
     MACH XA
     NAMESAVE MONDCSS
     IUCV *MONITOR MSGLIMIT 255
```

Start Monitor. Issue the following commands from a privileged id to enable and start monitor

     CP MONITOR SAMPLE ENABLE ALL
     CP MONITOR EVENT ENABLE STORAGE
     CP MONITOR EVENT ENABLE PROCESSOR
     CP MONITOR EVENT ENABLE I/O ALL
     CP MONITOR EVENT ENABLE APPLDATA ALL
     CP MONITOR START

Start MONWRITE. From the userid generated, issue the following command to collect data to a file id of MONITOR DATA B
```
     MONWRITE MONDCSS *MONITOR DISK MONITOR DATA B
```
Or enter the following to collect data to a tape attached as 181
```
     MONWRITE MONDCSS *MONITOR TAPE 181
```
Stop MONWRITE and Monitor. From the writer id issue
```
     MONWSTOP
```
From privileged id, issue
```
     CP MONITOR STOP
```

Background

If the above cheat sheet seemed too simple, read the following for a discussion of why and what the above is doing.

If you currently don't run Monitor, you'll need to create a DCSS. Example commands (note DCSS size depends on config and domains collected). The RSTD option states that only a userid with an appropriate NAMESAVE statement in its directry entry can load the segment. This is for security reasons. The segment is define for a total of 10 meg starting at the 35 meg. You need to make sure there are no other segments in the userid that overlap with this one.
```
     CP DEFSEG MONDCSS 2300-2FFF SC RSTD
     CP SAVESEG MONDCSS
```
NOTE: A default MONDCSS definition is provided with your z/VM system. See the Guide for Automatic Installation, Chapter 9. "Contents of Your z/VM System" under the section titled "Saved Segments on the z/VM System".
More details on the Monitor DCSS size are available.
If you currently don't run Monitor, you will also need to set up a userid to collect the data. Create a userid as you would normally and add the following statements.
```
     MACH XA
     NAMESAVE MONDCSS
     IUCV *MONITOR
```
The virtual machine will run CMS and needs to be an XA or XC mode machine. The NAMESAVE options allows the virtual machine to load a restricted DCSS. This is not needed if you do not use the RSTD option on the earlier DEFSEG command. The IUCV statement allows the virtual machine to connect to the Monitor CP system service.
NOTE: A default MONWRITE userid is provided in the USER DIRECT file on the MAINT 2CC minidisk provided with your z/VM system.
Typically, we enable for all SAMPLE data. Some people only include DASD devices in I/O Domain. The following EVENT domains are also of interest: STORAGE, PROCESSOR, I/O (not SEEKS!), and APPLDATA. Enabling the SCHEDULER domain in general is not a good idea because of the volume of data it creates. For scheduler related problems, enabling for a dummy user (such as $SPOOL$) can be of help. There are times when Seeks data is helpful, but in general I do not recommend collecting it. The following commands accomplish the above.
```
     CP MONITOR SAMPLE ENABLE ALL
     CP MONITOR EVENT  ENABLE STORAGE
     CP MONITOR EVENT  ENABLE PROCESSOR
     CP MONITOR EVENT  ENABLE I/O       ALL
     CP MONITOR EVENT  ENALBE APPLDATA  ALL
```
Data should cover "good" times as well as "bad" times if possible.
The monitor interval is the amount of time inbetween the CP monitor collecting data written as sample records. The interval should be small enough to get many samples, capture the problem, and not risk counters wrapping. For VMPAF analysis it is nice to have at least 100 samples. If the problem being diagnosed is a system slow down that only occurs for 2 minutes, a 3 minute sample interval is too large since the problem could come and go between samples. Some counters can start to wrap after 15 minutes. The interval size needs to be balanced as the smaller the interval, the more data is collected. The default is 1 minute. It can be changed (for example) to 5 minutes.
```
     CP MONITOR SAMPLE INTERVAL 5 MIN
```
Start the CP monitor.
```
     CP MONITOR START
```
Start the virtual machine configured to collect monitor data. It will need access to the MONWRITE utility.
```
     MONWRITE MONDCSS *MONITOR DISK fn ft fm
  or MONWRITE MONDCSS *MONITOR TAPE 181
```
To Stop issue "MONWSTOP" for MONWRITE and MONITOR STOP for CP.
See CP Command and Utility Reference for info on MONITOR COMMANDS and MONWRITE (note monwrite is in back of book with other utilities)

ROT (Rule of Thumb): raw monitor data size in bytes

         (users * 500 + devices * 450)* samples
     example: 5 minute interval for 8 hour prime shift with 1000 users
              and 500 devices would be
        (1000*500 +500*450)*(8*60/5) = 66 meg (about 95 3390 cylinders)

If collecting to disk, make minidisk ineligible for MDC (MINIOPT NOMDC)
MONWRITE format is best for us; if not we must know true format.
If you collected data to disk, but want to send a tape. You can use TAPE DUMP, VMFPLC2 DUMP, or PIPELINES. Please do not use DDR or SPXTAPE or SPTAPE. Please, also tell us what format you used.
RTM should be collected over the same span of time if possible.
Please note the type of tape drive used (compression, 3480 vs 3490, etc.).

FTP Considerations

If you need to move the raw monitor data by FTP, there are a few things to keep in mind:

Monitor data should be treated as binary data
If you are FTPing from another platform to VM,then use BINARY F LRECL 4096 and QUOTE SITE FIX 4096 to ensure the file gets there as a binary file of fixed records of size 4096.
If you forget to do the above, you can often recover with the following Pipelines command on VM - PIPE < mondata_file_id | FBLOCK 4096 00 | > mondata_file_id F 4096

If the file is on the PC and you can edit it and read dates, volsers, userids, then chances are someone moved it as Text and it was translated from EBCIDIC to ASCII. This is not good.

Back to the Performance Tips Page