Nonpaged pool problem

[John A. Beard]

Assistance requested please.

Can anyone please advise as to what I can do to resolve the problem reported below. I appreciate that this may well be a question that does not have a simple answer, but any pointers would be really welcomed.

The Robomon utility we use reported the following problem associated with pool usage.

Event Type: PROBLEM
Status: Deleted
Node: MOV008
Date/Time: 17-OCT-2007 12:00:00 AM
Class: SYSTEM
Severity: 3
Subclass:
State: UPDATE
Handle Number: 0
Handle Name: POOL_USAGE
Handle Context: MOV008
Creation Date/Time: 16-OCT-2007 2:00:00 PM
Closed Date/Time: None
Update Count: 11
Problem Owner: SYSTEM
Brief Text: POOL_USAGE - The largest block of free nonpaged pool on MOV008 is 280960 bytes; 0.91% of the total (30933568) free nonpaged pool.

Full Text:

The largest block of free nonpaged pool on MOV008 is 280960 bytes; 0.91% of the total (30933568) free nonpaged pool.

The nonpaged pool is fragmented, even though there may be sufficient memory nonpaged dynamic memory available. This is a result of nonpaged dynamic memory expanding beyond the initial size defined by NPAGEDYN.

Attached document shows some of the memory resources for the system in question.

[Ian Miller.]

What version of VMS?

On some versions there was a problem which lead to non-paged pool fragmentation. To fix that problem set these two system parameters
NPAG_GENTLE
NPAG_AGGRESSIVE
to 100

[Ian Miller.]

having paged down to the end of the attachment I see you have set those parameters.

In this case do

ANAL/SYS
SHOW POOL/NONP/SUMM

to see what is using the pool.

[John A. Beard]

Hi Ian,

Thanks for the reply. Please find attached the output you requested. If I'm reading the output correctly, "Unknown" appears to be the largest user of non-page pool... can this be drilled down further

[John A. Beard]

Sorry, missed an earlier question from you... OpenVMS 7.3-2

[Wim Van den Wyngaert · Accepted solution]

I would put NPAGEDYN to 50 MB (and reboot). You have it on 36 MB which is too small and thus is was expanded to its current 46 MB. And because it was expanded, it was first full, thus only small parts remain until something releases npag.

Wim

[John A. Beard]

Thanks Wim,

Before I make any modification in modparams.dat, could you let me know if the
AGEN$PARAMS.REPORT; should have notified me of a recommended increase?. Below is an extract taken from a short while back. In case I specified a wrong parameter for generating the report, couuld you please specify the full AUTOGEN command string to generate the output I should be looking at... thanks.


NPAGEDYN parameter information:
Feedback information.

Old value was 38674432, New value is 38674432
Maximum observed non-paged pool size: 38674432 bytes.
Non-paged pool request rate: 61 requests per 10 sec.

AUTOGEN parameter calculation has been overridden.
The calculated value was 36741120. The value 38674432 will be used in accordance with the following requirements:
NPAGEDYN minimum value is 38674432.

[John A. Beard]

Wim,

I just ran autogen with the following command

@sys$update:autogen savparams testfiles feedback

I can see that the recommended value has indeed increased....

NPAGEDYN parameter information:
Feedback information.

Old value was 38674432, New value is 46047232
Maximum observed non-paged pool size: 48504832 bytes.
Non-paged pool request rate: 61 requests per 10 sec.

[Ian Miller.]

I would go with the bigger value (48504832)

[John A. Beard]

Thanks to everyone for their input

[John Gillings]

John,

AUTOGEN was designed in an age when resources, and particularly memory, was far more expensive than it is today. Although OpenVMS engineering has done some updating of the algorithms, they're still not completely up to date in terms of relative costs of resources. Sticking a finger in the air... they're probably appropriate for an Alpha system from about 1999 with up to 500MB of main memory and 20GB of disk space.

Also remember that AUTOGEN isn't so much a fine tuning tool, as one that will give you a conservative configuration that's guaranteed bootable. If your system is younger than my hypothetical 1999 Alpha, or with significantly more resources, you can well afford to be FAR more generous than AUTOGEN recommends.

If you don't have any apparent problems with what AUTOGEN has set, then let the sleeping dog lie, BUT if you're having any kind of issue, it's better to leapfrog the AUTOGEN recommendation to potentially avoid another round of error/increment/reboot.

In this case, even thinking about an NPAGEDYN difference of 10MB isn't worth your time. Consider the cost of that memory, and the proportion of your total. Round it up to the nearest single digit of precision and be done with it. Go 50MB or even 60MB. We're well past the days when "wasting" 10MB of RAM was a serious problem, especially for a key resource like NPAGEDYN