Storage Preallocation
Member KLKINSTG of &rhilev.RLSPARM enables you to tune certain aspects of CL/SuperSession storage management and reduce the product's overall requirement for real storage. KLKINSTG also allows preallocation of storage subpools in order to reduce working set size.
True working set size is the number of pages that must be in primary storage (central and extended) if CL/SuperSession is to execute efficiently for a given workload. It is the amount of real storage the product requires in order to deliver good response time to a particular number of active users. Since true working set size is hard to measure, z/OS® reports working set as the number of pages that reside in primary storage at a given moment. This number may be larger or smaller than the true working set, but it can serve as a rough indication of true working set in a storage-constrained environment.
Storage managed by CL/SuperSession can become fragmented over time, leading to a larger working set than necessary. KLKINSTG provides a way to reduce this fragmentation by having CL/SuperSession preallocate an area of storage for small control blocks that are frequently obtained and freed.
KLKINSTG provides for preallocation of storage subpools with the default settings found in the KLKINSTG member of the initialization library &rhilev.RLSPARM.
The ACCESSED field of the output displays the number of times a block is allocated and released from a particular storage subpool. You can use this field to determine the relative activity of each storage subpool.
To preallocate storage subpools, use the following procedure.
- Analyze the STORAGE DETAIL command output during peak periods of system activity. Look at the
USE count for the small blocks, such as SIZE(1-16) and SIZE(17-32).
KLKSD003 ALLOCATION DETAIL: KLKSD004 SIZE(1-16) USE(20) TOTAL(105) ACCESSED(1204) KLKSD004 SIZE(17-32) USE(0) TOTAL(1) ACCESSED(27) KLKSD004 SIZE(33-48) USE(5) TOTAL(6) ACCESSED(67) KLKSD004 SIZE(49-64) USE(1) TOTAL(2) ACCESSED(243) KLKSD004 SIZE(65-80) USE(1) TOTAL(8) ACCESSED(24696) . . . KLKSD004 SIZE(16385-32768) USE(0) TOTAL(3) ACCESSED(101)The SIZE field shows the range (in bytes) of data block sizes in the subpool. For example, SIZE(1-16) indicates that this area contains all blocks that are from 1 to 16 bytes long. The USE field shows the number of blocks in use. The TOTAL field shows the total number of blocks that have been allocated.
The important block sizes to focus on for preallocation are 16, 32, 64, 80, 256, and 512 byte blocks from extended storage (storage above the 16MB line).
The KLKINSTG member contains the SIZE parameter with default settings that preallocate storage for block sizes 16 and 32. The format of the SIZE parameter is
SIZE(nnnnnnn,mmmmmmm,c)nnnnnnn The number of bytes to preallocate per block (for example, 16 for SIZE 1-16).
mmmmmmm The number of blocks to preallocate (the TOTAL value for that subpool block size).
c The type of storage: primary (P) or extended (X).
Preallocating the smaller blocks (16- to 512-byte blocks) is critical to improving storage utilization, because these blocks tend to increase storage fragmentation. So, the smaller the block, the more benefits you may see with preallocation.
- Use the default SIZE parameters in member KLKINSTG for your first
run. The default settings of the SIZE parameter are
SIZE(16,100,P)>SIZE(16,500,X)>SIZE(32,500,X)Note: When extended storage is available, you should not need to tune primary storage, since its use is minimal. If extended storage is not being used, follow standard STORAGE DETAIL analysis to establish parameter values. - During a period of peak activity, record the USE count for each block size (those listed in item 1 on page 215) returned by the extended portion of the STORAGE DETAIL command.
- If the USE count for the small blocks is relatively high (a count over 1000), use this number to adjust the count of the default SIZE parameters in member KLKINSTG. You can enter SIZE parameters for each block that needs preallocation.
For example, the following display shows output from the extended STORAGE DETAIL command:
KLKSD002 EXTENDED MAIN STORAGE DETAIL
KLKSD003 ALLOCATION DETAIL:
KLKSD004 SIZE(1-16) USE(20) TOTAL(1629) ACCESSED(1204)
KLKSD004 SIZE(17-32) USE(0) TOTAL(1304) ACCESSED(27)
KLKSD004 SIZE(33-48) USE(5) TOTAL(32) ACCESSED(67)
KLKSD004 SIZE(49-64) USE(1) TOTAL(1191) ACCESSED(243)
KLKSD004 SIZE(65-80) USE(1) TOTAL(1545) ACCESSED(24696)
.
.
.
KLKSD004 SIZE(16385-32768) USE(0) TOTAL(3) ACCESSED(101)
With these calculations, specify the following storage configurations with the SIZE parameter in member KLKINSTG:
SIZE(16,1625,X) Enter a count of 1625 for subpool 16;
TOTAL count of 1629 rounded down to a
multiple of 5.
SIZE(32,1300,X) Enter a count of 1300 for subpool 32;
TOTAL count of 1304 rounded down to a
multiple of 5.
SIZE(48,30,X) Enter a count of 30 for subpool 48;
TOTAL count of 32 rounded down to a
multiple of 5.
SIZE(64,1190,X) Enter a count of 1190 for subpool 64;
TOTAL count of 1191 rounded down to
multiple of 5.
SIZE(80,1545,X) Enter a count of 1545 for subpool 80;
TOTAL count of 1545 rounded down to a
multiple of 5.
This example displays calculations for extended storage (X), but you would use the same procedure for primary storage (P).
If your working set size has been reduced, your preallocation has been successful. If not, you may want to run the system and try the calculations again.
It is important to define your preallocation sizes based on a loaded system. If you use numbers that are derived from off-hours, such as weekends, they will not be accurate for peak-hour usage when the counts are much higher.
If region storage defaults are changed (made smaller, for example), the preallocation default should be changed accordingly. If your environment changes—such as more users, or more sessions per user, or if you change the MINIMUM or MAXIMUM storage startup parameter in member KLSSYSIN—your preallocation should also be changed. In all cases, we recommend that you periodically re-evaluate your startup parameters.