Thanks to the folks who responded:
kstran_at_acxiom.com
will_at_dcs.rhbnc.ac.uk
Additionally, I finally got thru to a knowledgeable DEC support person
who was able to answer all my questions and get us going.
Here's the scoop:
> (1) It seems to me that:
>
> max-per-proc-address space
>
> should be equal to or greater than
>
> max-per-proc-data-size + max-per-proc-stack-size + maxtsiz
>
> Is this correct?
Sort of, but there may be more to it, and these things can vary in
relation to each other and to the requirements of the program. For instance,
I was told that if a program allocates a huge array at startup time, it'd
need more stack size.
> (2) I've gotten mixed info on the maximum value for max-per-proc-data-size -
> one source within DEC told me it should not exceed the amount of physical
> memory. Does anyone know if this is true?
>
Yes, this can exceed physical memory. Could be a problem for performance,
but otherwise it can be as big as you want to make it.
> (3) I've been told we need to be concerned with the value of vm-maxvas.
> The definition I've found of this param. is that it is the max. virt. address
> space for user maps - "see vm-mapentries".
>
vm-maxvas was explained to me the maximum address range that a process can
ever address - absolute upper limit, nothing can exceed it.
> (5) Is it true that if max-per-proc-address-space is 1GB, then even if
> there are multi-gigabytes of virtual memory a given process won't be able
> to use more than 1GB??
Yes, true.
> (4) What other params would be affected by modifying these?
>
I was told that in order of impact on process use of memory, params are:
vm-maxvas - this is the absolute limit
max-per-proc-address-space - 2nd tightest limit, as above except includes
indirect references like shared libs, etc.
max-per-proc-data-space - limited by address-space above.
I was also told that these numbers can be ridiculously large - DEC support
person has 512MB, had his params at 3 terabytes! The problem with this, of
course, is that if you have:
* a system running more than a dedicated process
or * a badly-behaved program
or * a malicious program
your system could easily meltdown. In our situation, we are running a single
dedicated process on the system, and we are going to assume that our
programmers
(it's an in-house program) know what they are doing - if they don't, then
they and we will learn when things do meltdown!
One respondant mentioned "vm-maxwire" as a fourth limit that would be
important, with the above free - I can see where that would be relevant,
as it's the max a process can "wire" into memory.
Another item that the DEC support person said was that adding parameters to
sysconfigtab and rebooting overrides parameters that were changed by
putting them in /sys/conf/HOSTNAME and rebuilding the kernel - sysconfigtab
holds the highest priority.
Interesting stuff. Thanks!
--
Judith Reed
jreed_at_appliedtheory.com
(315) 453-2912 x335
Received on Fri Nov 20 1998 - 16:40:36 NZDT