XBR1Y028@DDATHD21.BITNET (W. Reichenbaecher, HRZ) (03/15/87)
We have just moved from an old VAX 11/780 (with 4 Megabytes of old main memory) to a VAX 8500 (with 16 Megabytes of main memory). Sure we need more than 16 Megabytes since VMS will get larger and larger - but anyway we like to increase some of the SYSUAF-parameters, so users may profit as well from our larger main memory. So I ask you experts for advice. We usually have 30 - 35 simultaneous users (in our university environment - editing, compiling FORTRAN, linking, running Fortran programs, TeX and LEX =another text processing software, Kermit) Here follows our current entry of DEFAULT in SYSUAF : Username: DEFAULT Owner: Maxjobs: 0 Fillm: 20 Bytlm: 25000 Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0 Maxdetach: 0 BIOlm: 18 JTquota: 1024 Prclm: 2 DIOlm: 18 WSdef: 250 Prio: 4 ASTlm: 24 WSquo: 500 Queprio: 0 TQElm: 10 WSextent: 1000 CPU: 0 00:30:00 Enqlm: 30 Pgflquo: 10000 Any suggestions or hints wanted Thanks in advance Walter Reichenbaecher Bitnet: XBR1Y028@DDATHD21 ARPAnet: XBR1Y028%DDATHD21.BITNET@WISCVM.WISC.EDU
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (03/15/87)
You haven't given enough information for intelligent responses. At the very least, I'd need the output of a "SHOW MEMORY" command; also the output of a LIST/GLOBAL command from within INSTALL would help, as would descriptions of what software you might be running other than basic VMS. For example, at my site, optional/third-party software takes more memory than the kernel VMS system.
LEICHTER-JERRY@YALE.ARPA.UUCP (03/17/87)
We have just moved from an old VAX 11/780 (with 4 Megabytes of old main
memory) to a VAX 8500 (with 16 Megabytes of main memory).... [W]e [would]
like to increase some of the SYSUAF-parameters, so users may profit....
We usually have 30 - 35 simultaneous users (in our university environment
editing, compiling FORTRAN, linking, running Fortran programs, TeX and
LEX =another text processing software, Kermit)
Here follows our current entry of DEFAULT in SYSUAF :
Username: DEFAULT Owner:
Maxjobs: 0 Fillm: 20 Bytlm: 25000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 18 JTquota: 1024
Prclm: 2 DIOlm: 18 WSdef: 250
Prio: 4 ASTlm: 24 WSquo: 500
Queprio: 0 TQElm: 10 WSextent: 1000
CPU: 0 00:30:00 Enqlm: 30 Pgflquo: 10000
Most of your limits are not at all unreasonable. I would suggest only a
couple of changes:
Prclm: Increase considerably; I run with 10. This will NOT result
in any massive increase in the number of processes on your
system since most of the important quotas are pooled among
all subprocesses of a job, so will provide a limit when
significant real resources become scarce. A limit of 2 is
annoying since it doesn't let you run easily with a "kept
editor" - you need room for a "spare" subprocess for things
like quicky SPAWN's out of MAIL or debugging process dumps.
Fillm: I run with a limit of 30, but now that I think of it I may
raise that. This quota in and of itself is very cheap; any
attempt to abuse it will quickly result in the abuser running
out of BIO quota or other "real" stuff.
WSxxx: These are the obvious ones to change. I'd certainly increase
WSquo - what you have now is more or less the result of making
a "worst case" estimate: 35 users, 16 meg of memory, divide
and let each get 1/2 meg. But in fact if you really get all
35 users actually DOING anything at once your system will
slow to a crawl. I'd try something on the order 1024 for
WSQuo. (Why 1024 rather than 1000? I don't know, a habit
I've picked up from others around me; makes it easier to
convert from pages to meg, actually. But then try and explain
why typical values for Bytlm are things like 10240.)
WSExtent is pretty cheap - you might as well let people make
full use of all that memory at times the system is lightly
loaded. I'd increase that substantially - to perhaps 4-5000.
(Note that this make make little real difference for your job
mix. For certain kinds of usage - particularly those that
often move back and forth from only one or two jobs doing
anything to a whole load wanting memory - it may slow down
responsiveness a bit.)
WSDef could be increased a bit, but I doubt it would make any
difference you'd see.
Make sure your SYSGEN parameters are appropriate for the amount for memory you
have. In particular, try to have enough process slots (BALSETCNT) to avoid
swapping during all but peak loads. (A value of about 70-80 should do it,
less (50?) if people never use kept editors.)
-- Jerry
-------