|
HP OpenVMS Systemsask the wizard |
|
The Question is: I remember hearing something about VMS 7.0+ introducing something called "memory fragmentation." Supposedly, technically, with SRP, IRP, & LRPs going away, the NPAGEDYN pool can become fragmented over time. A reboot or some third party tool were the recommended solutions. Question: Is any of this true? If so, do you have any additional info? Thanks a lot! The Answer is : The Wizard suspects there may be confusion here with a discussion of the OpenVMS VAX V6.0 and OpenVMS Alpha V1.0 releases, with the then-new adaptive pool management design was first shipped, and confusion over the meaning of some of the nonpaged pool information displayed by the SHOW MEMORY command. (Code that allocated large blocks of pool and that then erroneously freed these blocks via multiple deallocations of smaller blocks, was found to have contributed to problems reported at that time, as well.) The design of the adaptive pool management was found to be sound (and the design continues to be used), and it was found to have significantly better performance than the older memory management design, and with memory requirements within +/- 5% of the older design. For some related information around a pool expansion problem that was corrected many years ago, please see the ECO kit(s) that superceed the VAXSYS01_061 kit. (For information from the VAXSYS01_061 ECO.) These old ECOs are not relevent to V7.x vintage releases. As is the case with disk fragmentation, some level of pool fragmentation is entirely normal and expected behaviour. The Wizard cannot reasonably recommend the use of any disk or pool defragmentation tool without knowing that the fragmentation is actually causing a visible performance problem. (And if it is, the Wizard would be interested in knowing more about the particular situation and application behaviour that has induced the fragmentation.) With large memory systems and OpenVMS Alpha V7.1, reclaimation can be disabled by setting the parameters NPAG_GENTLE and NPAG_AGGRESSIVE each to the value 100 -- this will cause the memory allocated to the lookaside lists to remain on the lists, and can reduce incidence of fragmentation. (There are cases where excessive pool fragmentation has been known to cause problems for some systems -- the systems where these cases have been seen typically involve large memory systems with large-scale locking activity.) With DECnet Phase IV on OpenVMS V7.1, there is a pool-related ECO kit available that should be installed: ALPSYSA_071. This ECO allows larger lookaside list packet sizes, and is intended to better support typical DECnet Phase IV pool usage.
|