NPAGEDYN expansion and expansion and ...

[Mike McKinney]

Hardware ES47

OS VMS 7.3-2 (And locked there because of the application)

Oracle 9i

Application: Sunguard/SCT Banner

Over the last few months I have autogenned at least every week and watched NPAGEDYN grow. It started with NPAGEDY Current around 4.1 Mb and now CURRENT is 7.57 and INITIAL IS 6.07.

If I don't reboot, the CURRENT value stays at one level. If I do reboot, it grows larger after a couple of days. With physical memory at 4 Gb I'm afraid to give it any more!

I have even boosted MIN_NPAGEDYN in MODPARAMS.DAT and every time the CURRENT grows.

Is this some kind of memory leak?

[John Gillings · Accepted solution]

Mike,

DON'T PANIC :-)

I wouldn't be at all concerned with those numbers. 8MB on a 4GB system is just noise! Many systems with far less physical memory have much larger NPAGEDYN allocations.

You could *easily* support an NPAGEDYN of 100MB on that system without any likely ill effects. This may just be changes in V7.3-2 affecting your resource consumption, and it may take a while to re-adjust SYSGEN parameters to suit.

Is it a leak? I'd guess not. Let the sytem run for a few weeks and watch the growth rate. If it doesn't plateau after a while, there may be a problem.

Things you can do to investigate -

Track the consumption over time. You can use the lexical function F$GETSYI to get items NPAGED_TOTAL, NPAGED_FREE, NPAGED_INUSE and NPAGED_LARGEST. There's also NPAGED_POOL to return all four in one hit, but you have to carve up the string afterwards (also works on lower versions).

From SDA, use:

SDA> SHOW POOL/SUMMARY

To see what packet types are consuming NPAGEDYN.

SDA> CLUE MEM/LOOK

Will show the lookaside lists. Look for excessively long lists.

[Mike Reznak]

Hi,
don't worry.
We have 6GB memory
NPAGEDYN 201998336 bytes
PAGEDYN 17997824 bytes

So you have plenty of free space to grow.
Let the autogen to suggest the values. And keep autogening till it settles.

Mike

[Ian Miller.]

if you work out what percent 8Mb is of 4Gb you will see it is trivial. Use the SDA commands given to see the usage. I would probably raise the initial value to 16Mb and see.

[Mike McKinney]

Thanks guys! My experience in the NPAGEDYN that ate Spit Brook Road (the place where the "pool" became and ocean) comes from VMS 4 and 5. It had me worried. I think I will boost it significantly and see what happens!

Thanks again!

Mike

[Marc Van den Broeck]

Hi Mike,

I use a NPAGEDYN of 20MB and I have 4Gb of physical memory, but I am using Oracle 8.1.7.4.

Rgds
Marc

[David Jones_21]

I booted my new DS15 (25,000 MB memory) on 24 June with an inital NPAGEDYN of 23.46 MB. After 72 hours uptime, AUTOGEN saw no growth and recommended reducing it. After 674 hours, AUTOGEN saw pool at 35.72 MB. After 2349 hours, pool was at 45.22 MB. Currently at 2600 hours, pool is at 47.00 MB, so it is growing slow enough that I don't worry about it.

Show memory (VMS 8.2) reports lock dynamic memory as 21.44 MB, I assume this is a separate pool in S2.

[Jeff Chisholm]

Lock manager dynamic memory is in S2 space. It isn't managed the same way at all.

[Paul Blaney]

Mike,

An expanded and potentially fragmented pool space is not as useful as getting the initial allocation right. Keep monitoring, and do review the autogen values. Considering it is non-paged and the 'raison d'etre', it is worth spending some time on this. If it grows automatically, then it is being used, therefore the system is helping you, though you don't want pointers being resolved all the time for multiple memory allocations...on a 4GB system, you will be protected from over-allocation. If you have to go above 1GB, then a more global review (my rule of thumb) of your memory use is recommended, not to say that value cannot grow larger.