By Akiko Hoshikawa, Bart Steegmans, Bituin Vizconde, and Paul McWilliams.
We recently received several questions about changes introduced in Db2 12 by APAR PH47163. It changes the Db2 12 real storage management behavior with the REALSTORAGE_MANAGEMENT=AUTO setting, which is the default and used by most customers. This APAR makes it easier to get the potential benefits of the REALSTORAGE_MANAGEMENT=OFF setting in Db2 12, without adjusting your settings.
Before we get into those details though, note that this blog only applies if you are still using Db2 12. Db2 13 for z/OS introduces significant optimizations to the management of thread memory, and Db2 13 automatically discards memory as needed. These improvements make the REALSTORAGE_MANAGEMENT subsystem parameter obsolete, and it is removed in Db2 13.
With APAR PH47163 and REALSTORAGE_MANAGEMENT=AUTO, Db2 12 monitors the available real storage on the LPAR, and when there is enough available real storage (which means more than 1.2 * MAXSPACE setting for SVC dumps), Db2 automatically switches to the behavior that is used when REALSTORAGE_MANAGEMENT=OFF is specified. Then if Db2 later detects insufficient available real storage on the LPAR, Db2 automatically switches back to discarding real storage frames, by using what is now called the AUTO1 behavior. APAR PH47163 also introduces a new DSNS006I message to inform you that Db2 is (automatically) switching to a certain type of real storage management behavior.
In short, the idea behind the APAR is that you can take advantage the potential benefits that come with REALSTORAGE_MANAGEMENT=OFF and avoid possible issues associated with storage discard operations, without changing your REALSTORAGE_MANAGEMENT setting. Also, you no longer have to monitor your system to make sure that you still have enough available real storage. After APAR PH47163, a Db2 system that uses REALSTORAGE_MANAGEMENT=AUTO gives you the best of both worlds: you avoid potential issues from unneeded real storage discard processing, and Db2 protects your system by automatically starting to discard frames again when the system is getting low on real storage.
Background
When Db2 started to exploit more memory above the 2GB bar to improve scalability and performance in version 10, real storage was a ‘scarce’ and rather expensive resource. Therefore, Db2 Development introduced a subsystem parameter REALSTORAGE_MANAGMENT that allows customers to control how Db2 releases real storage frames back to z/OS that are allocated to Db2.
In recent years, many customers have seen significant increases in their Db2 for z/OS workloads. The workload growth naturally leads to the higher storage demands and an increase in the number of concurrently executed Db2 threads.
Customers are investing in memory to cope with these increased workloads, but also to take advantage of performance improvements that can be obtained from utilizing more memory.
However, with increases in the size and the number of threads, Db2 customers have also started to see the impact of releasing the 64-bit memory associated with these threads.
REALSTORAGE_MANAGEMENT subsystem parameter
In Db2 12, the REALSTORAGE_MANAGEMENT subsystem parameter defines how and when Db2 releases real frames consumed for 64-bit threads in Db2 storage pools. To return the unused 64-bit real frames to z/OS Real Storage Manager, Db2 uses a z/OS service, IARV64 REQUEST=DISCARDDATA. We refer to the invocation of z/OS IARV64 service with DISCARDDATA as “discard” or “discarddata processing”.
The options for REALSTORAGE_MANAGEMENT are, AUTO, AUTO1, ON and OFF and it determines the discard behavior and frequency. The default value is AUTO.
REALSTORAGE_MANAGEMENT=AUTO
When you specify the AUTO option, Db2 monitors the available real storage on the LPAR. When it detects that the available real storage on the LPAR is more than the calculated threshold (REALAVAIL > MAXSPACE*1.2), Db2 automatically switches behavior as if option OFF is specified, and does not discard unused real storage.
When Db2 detects that the available real storage on the LPAR is less than the calculated threshold, Db2 behaves as if AUTO1 is specified.
Db2 issues message DSNS006I to indicate that it switches behavior:
DSNS006I csect-name DB2 WILL START TO BEHAVE AS REALSTORAGE_MANAGEMENT=value
Where value is either OFF or AUTO1
The DSNS006I message indicates that Db2 automatically changed its behavior for managing real storage because it detected that the amount of available real storage either exceeds, or no longer exceeds, the (REALAVAIL > 1.2 * MAXSPACE) threshold. (REALAVAIL is the amount of currently available real storage on the LPAR, and MAXSPACE is a setting that restricts the virtual storage available to the z/OS® DUMPSRV address space.)
(Note that with the initial APAR PH47163, DSNS006I was displayed as a highlighted message on the console. However, PH59758 removes the highlighting of the message based on customer feedback.)
REALSTORAGE_MANAGEMENT=AUTO1
Db2 discards thread storage at thread deallocation, or every 120 commits if the thread is reused.
If the available real storage on the LPAR drops below the z/OS frame Available Frame Queue Low threshold, Db2 enables “contraction mode”. In contraction mode, Db2 discards every 30 commits. The console messages DSNV516I and DSNS005I with a reason “LOW ON AVAILABLE FRAMES” indicate that Db2 is in contraction-mode.
DSNV516I csect name DSNVMON - BEGINNING STORAGE CONTRACTION MODE
DSNS005I csect-name DSNVMON - CONTRACTION INITIATED DUE TO LOW ON AVAILABLE FRAMES
When Db2 drops out of contraction mode, it issues the following message:
DSNV517I csect-name DSNVMON - ENDING STORAGE CONTRACTION MODE.
REALSTORAGE_MANAGEMENT=ON
Db2 always operates in contraction mode when REALSTORAGE_MANAGEMENT is ON, and the following console messages are issued.
DSNV516I csect-name DSNVMON - BEGINNING STORAGE CONTRACTION MODE
DSNS005I csect-name DSNVMON - CONTRACTION INITIATED DUE TO REALSTORAGE_MANANGENT=ON
Frequently discarding real storage frames results in some CPU overhead, and this option is intended for systems in which the availability of real storage is limited. This value is not recommended for production systems, but it might be appropriate for development LPARs that have many Db2 subsystems and a limited amount of real storage.
REALSTORAGE_MANAGEMENT=OFF
Db2 does not request discarddata processing at thread deallocation, nor at commit.
Tip: If for some reason you don’t like the autonomic real storage management behavior that you get with REALSTORAGE_MANAGEMENT=AUTO, or you notice that Db2 switches behavior too frequently, because your available real storage is close to the threshold value, you can specify AUTO1 to get the same behavior that you used to get with AUTO before PH47163. Only a value of AUTO enables the monitoring and autonomic change in real storage management behavior. If you specify ON, AUTO1, or OFF you get the specified behavior all the time.
KEEPREAL(YES/NO)
When Db2 issues IARV64 REQUEST = DISCARDDATA, Db2 specifies KEEPREAL(YES) option as described in APAR PM99575. The KEEPREAL(YES) option is used to reduce the overhead from constantly re-acquiring the frames immediately after releasing the ownership. However, this option makes monitoring of Db2 shared and common frames and estimating the required Db2 dump storage very difficult.
Unless the discarded KEEPREAL(YES) frames are stolen by non-Db2 usage, z/OS continues to account them under Db2, even though Db2 discarded the frames.
If a precise estimation is required, you can use a serviceability feature introduced by PI78979. Activating IFCID 0503 allows you to determine the amount of real memory truly allocated by Db2 at midnight in local time.
When severe storage constraints are detected, Db2 specifies KEEPREAL(NO)during discarddata processing. In that case the real frames backing the pages to be discarded are freed. They are no longer accounted to Db2 and are available for reuse by non Db2 applications.
One such condition is when a critical shortage on auxiliary storage is detected. In that case, messages DSNV516I and DSNS005I, this time with reason 'AUXILIARY SHORTAGE”, as well as message IRA201E CRITICAL AUXILIARY STORAGE SHORTAGE are expected.
Another severe storage condition occurs when you specify a value for the subsystem parameter, REALSTORAGE_MAX and the total amount of allocated Db2 real storage reaches the specified value.
REALSTORAGE_MANAGEMENT=AUTO1 implications
When using REALSTORAGE_MANAGEMENT=AUTO1 (or REALSTORAGE_MANAGEMENT=AUTO with AUTO1 behavior ‘active’), Db2 is a good citizen and frequently releases unused frames back to z/OS. However, excessive discard requests from Db2 can overwhelm the z/OS LPAR and might result in LPAR level serialization. This is observed as a significant increase in Db2 system service address space (SRB) CPU time in the Db2 statistics report, and/or RSMQ spin lock contention in RMF or SMF 98. In some cases, excessive discard can cause z/OS common storage shortage (ESQA) as z/OS utilizes z/OS common storage for discarddata operations.
Conclusion
When REALSTORAGE_MANAGEMENT=AUTO is used in Db2 12 with PH47163 applied, and you have enough available real memory in your z/OS LPAR, Db2 no longer triggers real storage cleanup that can result in CPU increase in the system service address space from CPU spin conditions. So, the recommendation is to use REALSTORAGE_MANAGEMENT=AUTO in Db2 12.
Customers who are confident that they always have enough available real storage and are currently running with REALSTORAGE_MANAGEMENT=OFF can continue to do so. (For more about determining when it is safe to run with REALSTORAGE_MANAGEMENT=OFF, see our previous blog).
However, if these customers change to REALSTORAGE_MANAGEMENT=AUTO they can benefit from the monitoring that Db2 does on their behalf and the capability to start discarding storage again if the system ever does get low on real storage.
#Db2forz/OS#Db2z12#Db2Znews