SYSVIEW increased VLF memory following upgrade to z/OS 2.3
search cancel

SYSVIEW increased VLF memory following upgrade to z/OS 2.3

book

Article ID: 205143

calendar_today

Updated On:

Products

SYSVIEW Performance Management

Issue/Introduction

Customer is currently upgrading from z/OS v2.1 to v2.3.
With this upgrade to z / OS v2.3, VLF suddenly started to use a lot of memory.

Customer asked IBM to investigate and received the answers below.

The DATASPACE (DCSVLLA) PAGE associated with LARGE FRAME (1MB) is continuously referenced by the SYSVIEW module, increasing VLF usage.

Customer also checked the operation with their test system and noticed that VLF memory usage was increasing at the time of the first SMF interval change after launching SYSVIEW.

Per IBM from the dump;

the srb module owned by SYSVIEW continued to refer dataspace page in DCSVLLA at psw 101182C4 (instruction 58001000) while the page is backed by pageable large frames. 
Once the page was backed by 4K frame, the reference stopped.

From 10000000 to 6C7FF000 pages in DCSVLLA were backed by pageable large frames by that reference. Both 6C800000 and 70000000 were backed by one 4K frame by that reference. 

Environment

z/OS 2.3

Cause

Review of the dump revealed:

The reason for the real storage increase is; counting the Useblk data field value, we 'touch' all pages in the data space which results in those pages being paged-in by the operating system's memory manager, thus the increase in real storage. 

SYSVIEW support needed to verify if customer or other users on the system are frequently issuing the DSLIST command.

This applies to all address spaces that own a data space, not only VLF. 

Resolution

 Customer needs to set the NOUseBlk option in DSLIST for the capture userID profile.

See HELP DSLIST on how to set that option.
Doing so, SYSVIEW will not count and display the UseBlk field, thus not needing to page-in dataspace blocks into real storage. 

To find out what the current DSLIST setting is

  1. PROFILE SWITCH captureUserID
  2. DSLIST
  3. OPTIONS
  4. Customer will be presented with "GSVX739I DSLIST options: " followed by the current OPTIONS settings  
  5. Switch back to customer profile: PROFILE SWITCH UserID

If GSVX739I shows USEBLK which it will most likely be the case, customer can change the setting by issuing

  1. PROFILE CHANGE CaptureUserID
  2. LINK DSLIST
  3. OPTIONS NOUSEBLK
  4. PROFILE SAVE 
  5. Exit 'PROFILE CHANGE'. Simply return to the main menu

Or:

Remove DSLIST from the capture OR reduce the frequency of which DSLIST is issued.

If customer publishes a Capture member with DSLIST with this CAPTURE member, DISABLE will lower the VLF value.

By capture we are referring to the capture event that is issuing the DSLIST command. 

To find out which CAPTURE events are scheduled,  

  1. Issue SCHEDULE; SEL FUNCTION EQ CAPTURE
  2. Note all the PARMS data fields for all CAPTURE events scheduled. The PARMS data field represents the CAPLIST member that contains the command to be issued for the capture. 
  3. Issue CAPLIB
  4. Search the libraries (User, Site, or SYSTEM) for the members that are referenced by the CAPTURE event (PARMS data field from above step) to see which member has the DSLIST command.
  5. Remove DSLIST, if desired.

If customer publishes a DSLIST with this CAPTURE member, DISABLE will lower the VLF value.

Removing DSLIST from the CAPTURE (or setting OPTIONS NOUSEBLK) will no longer cause SYSVIEW to page-in (by means of z/OS memory manager) the VLF dataspace pages, which is the symptom shown by the dump analysis. Thus, not leading to the increase in VLF real-storage value.  

The VLF real-storage value will get lower if the z/OS memory manager decides to page those pages out of real storage.

Which will eventually happen if those pages are not referenced. SYSVIEW  has not control over how or when that is done since that's a function of the operating system.