The Storage Level
Storage (or memory) is a very important part of the system. Understanding storage utilization is critical and will depend greatly on workload. Paging happens when storage/memory is not available and data has to be written to disk. It is much more efficient to use storage as well as improving response times. Paging can cause severe system performance issues. Defining storage varies with traditional CMS workloads and Linux workloads. The amount of total storage, the size of the Dynamic Paging Area (DPA) and the size/type of paging disks all come into play for the most efficient performance of the system. One of the top reasons for a first-time installation having a z/VM outage is from lack of proper page space planning. If running out of page space, the system will take a PGT004 abend.
For more information about paging, see System Page analysis.
For a presentation on the Storage/Paging environment and utilization, see z/VM Storage Analysis and Tuning
Helpful configuration settings:
- Storage requirements should be reduced as much as possible to avoid unneccessary paging delays. Plan on 2GB of
storage for z/VM, MDC and infrastructure (TCPIP/DIRMAINT/zVPS).
Review options for reducing storage requirements BEFORE analyzing or enhancing the paging subsystem. Often if storage is added when not necessarily needed, CPU will go up as work is
not being delayed by paging. Watch batch windows for any work delays during high utilization. - Linux - the over-commit ratio is the planning target. IE - For 20 Linux servers at 1GB each with a target over-commit
ratio of 2, 12GB will be required.
For WAS and Domino environments, an over-commit target of 1.5 is reasonable. For Oracle and other virtual friendly applications, an over-commit of 3 is reasonable.
(# of servers x server size / 2 plus 2GB for z/VM = storage requirement) - If adding more Linux servers, decrease the Linux server storage size until they start to swap. This is an easy tuning knob available to improve storage utilization!
- It is recommended to set the values for the global aging list to help manage pageable storage. Set the size to
5%, earlywrites to yes and keepslot to yes.
SET AGELIST SIZE 5% EARLYWRITES YES KEEPSLOT YES - Recording account data uses a lot of storage - it can be turned off in the SYSTEM CONFIG or with CP RECORDING ACCOUNT OFF PURGE.
- Another space saving setting is to limit the Trace Table size with CP SET TRACEFRAMES MASTER 100 ALTERNATE 75 PERCENT.
- Minidisk Cache (MDC) defaults to 'all of it', set it down (ZVPS does use MDC!). SET MDC STORAGE 128M 1282M
- Minidisks used for Linux file systems and for swap should have MDC turned OFF to avoid redundant levels of caching.
The storage subsystem analysis should be done top down:
- z/VM - how the overall system is set up/running.
- Virtual machines - how users/servers are set up/running.
- VDISK/MDC/Address spaces - how the system processes are set up/running.
- Linux servers/processes - how the Linux servers are running.
Helpful ESAMON screens/ESAMAP reports:
- ESASTRC - Main Storage Configuration - Shows the configuration information for the main storage area.
- ESASTR1 - Main Storage Analysis - Shows information about the dynamic paging area.
- ESASTR2 - Main Storage DPA Analysis - Shows additional information about the dynamic paging area.
- ESAXACT - Transaction delay analysis - shows an analysis of virtual machine states and wait states.
- ESAUSPG - User Storage Analysis - Shows information about user storage utilization.
Using zVPS to find information for solving issues with the storage/paging level:
ESASTRC - Shows storage configuration information.
ESASTR1 - Shows storage analysis information.
ESASTR2 - Shows additional storage analysis information.
ESAXACT - Transaction delay analysis. This can show if users are waiting on paging operations. Helpful storage/paging information:
ESAUSPG - Shows user storage information. Both screen and report samples:
Conclusions
Review the options for reducing storage requirements before analyzing or enhancing the paging subsystem. Many times storage requirements can be reduced so that paging requirements drop significantly. If this is the case, any time spent on the paging subsystem will be wasted. Spooling rarely impacts performance. Have sufficient number of spool volumes to keep the device busy at less than 20% during peak periods.
Back to top of page
Back to Performance Tuning Guide