🚀 go-pugleaf

Your problem probably resides with '...a nominally single-user system'.
Apparently, your user with the enormous working set gets trimmed down to
his WSQUO. This is done by the swapper before starting to swap in an effort
to recover physical memory - somebody else (the non-nominal users!) requested
it. As the swapper doesn't really know how much it might need, it just cuts
your poor user down to WSQUO (which is guaranteed to every process in the
system).

There are three possibilities I can see (not all exclusive) to help in this
situation:

1 - Make it a real single user system or more severely restrict the number
    of user you allow to log in.

2 - Raise the WSQUO for your special user so he his guaranteed a larger share
    of memory. You could have the login file set the actual WSQUO for the
    process to a lower value and a command file raise it to the authorized
    value just before your monster of a program is run.

3 - Increase WSINC. This will allow the program to reach full strength as
    quickly as possible when it does get trimmed, but works on a system-wide
    basis and might generate problems from the other users.

Finally, check you aren't wasting memory elsewhere: Check the sizes of nonpaged
pool (AUTOGEN tends to grossly oversize them, especially in such an environ-
ment). Check you aren't wasting memory on too large a system working set:
Only install the images which are really shared /SHARED, reduce the parameter
GBLSECTIONS to its necessary minimum, same for GBLPAGES and PAGEDYN.
And last, if you're using NETSERVER heavily, consider applying a small patch
(which DEC should have supplied since VMS 3.5...) to make it purge its
working set before it goes to sleep. This typically saves 200-250 pages per
NETSERVER process.

 -- Jan