z/OS Language Environment Programming Guide for 64-bit Virtual Addressing Mode
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Tuning heap storage

z/OS Language Environment Programming Guide for 64-bit Virtual Addressing Mode
SA38-0689-00

For best performance, the initial heap segment should be large enough to satisfy all requests for heap storage. The Language Environment storage report generated by the RPTSTG(ON) runtime option shows you how much heap storage is being used, the total number of segments allocated to the heap, the statistics for the optional heap pools algorithm, and the recommended values for the HEAP64, LIBHEAP64, IOHEAP64, HEAPPOOLS64, and HEAPPOOLS runtime options. You can use this information to tune your application to minimize the number of segments allocated and freed.

The heap pools algorithm (see Using heap pools to improve performance) can be used to significantly increase the performance of heap storage allocation, especially in a multi-threaded application that experiences contention for heap storage. However, if the algorithm is not properly tuned, heap storage could be used inefficiently.

Tuning the HEAPPOOLS64 algorithm for an application is a three-step process:

  1. Run your application with the runtime options HEAPPOOLS64(ON) or HEAPPOOLS64(ALIGN) as appropriate (using the default cell sizes and counts), and RPTSTG(ON) for some time with a representative application workload. Then examine the HEAPPOOLS64 Statistics and HEAPPOOLS64 Summary" sections of the Storage Report for Enclave report.
  2. Change the cell sizes in the HEAPPOOLS64 runtime option to the Suggested Cell Sizes column from the first run. Rerun the application with a representative workload, using the default counts in the HEAPPOOLS64 option. Examine the storage report.
  3. The values listed in the Maximum Cells Used column of the HEAPPOOLS64 Summary should be the optimal values for the counts to minimize storage use. For a cell size that has multiple pools, the correct value to use is the largest "Maximum Cells Used" value for that size multiplied by the number of pools for that size.

Any time there is a significant change in the workload, repeat these tuning steps to obtain optimal HEAPPOOLS64 values.

Tuning the HEAPPOOLS algorithm for an application is a three-step process:

  1. Run your application with the runtime options HEAPPOOLS(ON) or HEAPPOOLS(ALIGN) as appropriate using the following cell sizes and percentages:
    (8,10,32,10,128,10,256,10,1024,10,2048,10,3072,1,4096,1,
    8192,1,16384,1,32768,1,65536,1)
    and RPTSTG(ON) for some time with a representative application workload. It may be necessary for the application to increase the region size.
  2. Change the cell sizes in the HEAPPOOLS runtime option to the Suggested Cell Sizes from the first run. Rerun the application with a representative workload, using the default percentages in the HEAPPOOLS option. Examine the storage report.
  3. The values listed as Suggested Percentages for Current Cell Sizes are the recommended values to minimize storage usage. Evaluate these values before finalizing cell pool sizes.

Any time there is a significant change in the workload, repeat these tuning steps to obtain optimal HEAPPOOLS values.

RPTSTG(ON) and the STORAGE runtime option can have a negative affect on the performance of your application. Therefore, always use the IBM-supplied default setting RPTSTG(OFF) when running production jobs. Use RPTSTG(ON) and STORAGE(xx,xx,xx) only to debug applications. See z/OS Language Environment Programming Reference for more information about RPTSTG and STORAGE.

Usage notes:
  1. These recommendations are dynamic and represent values for this particular run. The values may change with each run performed.
  2. Long-running applications may have an adverse effect on the statistical data collection. Fixed-length counters may overflow, causing incorrect HEAPPOOL recommendations. If the recommendations appear to be unrealistic, rerun with a reduced application run time.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014