From: HENRY::IN%"leichter-jerry%yale.arpa%sri-kl.ARPA%relay.cs.net@rca.com" 17-MAR-1987 19:49 To: "W. Reichenbaecher HRZ" Subj: Re: increased main memory - what to change in SYSUAF? 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 -------