System Page

System Page Analysis

Specifics - System page analysis:

Paging happens when the storage subsystem does not have enough memory to complete its work. Paging involves writing data out to disk which causes the DASD subsystem to work harder. Using the screens/reports below, it can determined if there may be paging occurring which will cause performance impacts. Reports are always good for trending, finding the time a problem started and determining 'prime time' slots.

IBR stands for Invalid but Resident. It is part of the new storage concept that replaces XSTORE (expanded storage) for handling memory activity as of z/VM 6.3. It contains several frame/page lists. When the system needs real storage (memory), the algorithm selects frames/pages from the user and system owned lists. These pages are put in IBR state. Any access to a page in IBR state by guests results in revalidation. Otherwise, the frame associated with an IBR page is added to the global aging list to be reused.
Linux servers tend to do polling which causes the server to look at data then go back to sleep. If the pages it touches at each dispatch get paged out (moved to disk), the system page rate goes up. There are ways to adjust IBR as a high page rate will cause system performance impacts - shown on IBR analysis.

Helpful configuration settings:

Critical - Page space must be no more than 75% allocated! More than that, blocking factors drop and page I/O goes up.
Paging storage should be 2 times the requirement.
It is recommended to use consistent naming conventions for page and spool devices so they are easily identified.
Ensure paging devices are dedicated.
Paging devices should have multiple channel paths.
Ensure a paging device has only page space allocated - no other kinds of data.
Ensure paging devices are all the same size - such as 3390-3 or 3390-9, etc.
Ensure paging devices do not exceed 20% busy. Allocate the same page space to each paging device to ensure the load is balanced at peak intervals.
It is recommended to set the size for the global aging list to help manage pageable storage. Set the size to 5% with SET AGELIST SIZE 5%.
If paging is an issue due to DASD speed, the use of solid state DASD (SSD) for paging devices is recommended.

Page devices are usually in the top ten DASD so that is not necessarily an issue. If a device busy is over 20%, this is cause for concern. If a device busy is over 50%, it can indicate a serious problem. Minute by minute analysis on the ESADSD2 screen (shown below) would show a 30% peak.

Helpful ESAMON screens/ESAMAP reports (further explained below):

ESAPAGE - Paging and Spooling Analysis - Shows paging/spooling activity.
ESAPSDV - Page and Spool Device Activity - Shows paging/spooling configuration and utilization.
ESADSD2 - DASD performance analysis Part 1 - Shows how the current DASD is performing.
ESABLKP - Block Paging analysis - Shows the activity rates associated with block paging activities.

ESAPAGE - Shows paging/spooling activity. This is the easiest way to see paging activity.

Pages Read Write - This is an indication of how much paging is happening on the system. Watch for significant changes.

InUse - This is also an indication of how much paging is happening. Watch for significant changes. If the InUse for Page is over 50% (InUse/Avail) then page space should be increased.

Page Space Threshold passed - This shows how often the threshold for paging was passed. The default is 90%. If this threshold is continually passed, more page space is needed.

Spool Activity - Files/min - Creat - This shows the rate of spool files being created per minute. If this number is over 50, a user may be 'flooding' the system, creating spool files too quickly and may cause the spool space to fill. Check ESAUSP2 to see who may be the culprit.

ESAPSDV - Shows paging/spooling configuration and utilization. Both screen and report samples:

Serial - This shows the volsers of the paging and spool packs. This can show if there are individual packs that are being over used or other possible issues. Note the serial names to check on the ESADSD2 screen/report.

Read Write - This shows the rate of reads and writes to each pack. The more activity, the more paging. The more paging, the worse performance becomes. Use the report for trending and long term analysis.

Spooling %Use - This shows the current spool percentage in use. If it is over 50%, analyze the spool and purge large or unused spool files. It might also be a looping user filling the spool who will need to be contacted or forced. If the spool in use percent gets to 100%, no more spool files can be produced.

Serv Time/Resp Time - These show the service and response times for page devices. If either of these numbers are over 20 milliseconds, this is a problem. Check the system problem DASD flow chart section for DASD/cache issues.

ESADSD2 - Shows DASD performance. Look for the paging devices seen above. Both screen and report samples:

Device Number - This shows the device number and model number for the head of string. Can click (zVIEW) or zoom (z/VM) to see the all of the devices on the string. This will first show all the devices that have activity.

%Device Busy - This shows the elapsed time a device was busy (if not seeing the whole string, the head of string will show the total for that string). Look for high numbers on paging packs. The ESADSD2 report shows the top DASD by Device busy. Look for the paging devices.

SSCH Average/Peak - This shows the amount of start subchannel commands were issued per second on average and the peak. This indicates which DASD are the most busy.

Response Times - This shows different aspects of how the devices are functioning. High Response/Service times can show a dysfunctional or overworked device. High Pending/Disconnect times can be an indication of a cache problem. High Connect time may indicate faster channels are required.

Queueing - This shows the different ways a device can queue. It shows where the queuing is happening - in the device vs the control unit vs I/O throttling (where multiple entities are after the same data). Response time should be the same as Service time or there is queueing.

ESABLKP - Shows the block paging analysis. Both screen and report samples:

Reads - This shows block page reads. Optimal is 10 pages.

Steal - This shows pages stolen/unreferenced. This indicates storage stress.

Migrate - This shows pages migrated. After z/VM 6.3 this will be zeros as this is moving pages from XSTORE to DASD and XSTORE is no longer suggested for paging.

Single Read - This shows single reads where block paging wasn't able to be used. This went up with z/VM 6.3 and beyond.