edhall%rand-unix@sri-unix.UUCP (01/12/84)
Right away your 64 lines eat up 64 process slots, assuming each one of them is potentially able to be used at any one time. Then, you need about 4 more process slots per user at maximum load (which I hope is considerably less than 64). This is NPROC. Give each of these users about 8 inodes (NINODE) and 8 file-table entries (NFILE). The CMAPSIZ and SMAPSIZ should probably be increased to 100 to be conservative (they don't take much room), though the manual is theoretically correct. 256K (512 blocks) of swap per user should be quite generous. I've seen systems with less than half of this ratio which have never run out, even though they run large multi-process programs like Ingres. The size of your C-list should be about 15 nodes per user (I forget what the parameter name for this is) if you have the standard 16-byte Clist element and terminal driver. Time-callouts (NCALL) are very system-dependent, but if you use terminal delays better make this one at least equal to the number of users plus twenty. If you don't, and there are no other device drivers on the system which use them, then 20 total may be enough. Text segments are also ver system-dependent. Allocate one of these per program with the `sticky-bit' set, plus one or two per user, depending upon how many of your programs have pure texts. Then, take it up to 48K with buffers (NBUF). Note that both the number 6 and 7 segmentation registers are used for other things; 7, as you say, for the I/O page, and 6 for mapping in per-process data. If the number of buffers is too small, you'll have to start pruning other tables. Inodes, files, and processes are the three places to cut. All I have described is for vanilla V7 UNIX. 2.xBSD systems and others that allow kernal overlays will be different. And I'm sure others might disagree with some of my suggestions. But they should be a good starting-point. -Ed Hall Rand Corporation edhall@rand-unix (ARPA) decvax!randvax!edhall (UUCP)
edhall%rand-unix@sri-unix.UUCP (01/12/84)
A correction: a better figure to use for NINODE and NFILE is about 12 per user, plus one NINODE per shared-text program in common use. If you have applications which use lots of pipes (such as Ingres), increase NFILE as well. -Ed
phil@amd70.UUCP (Phil Ngai) (01/14/84)
In the document "REGENERATING SYSTEM SOFTWARE" there is a section called
"System Tuning" which talks about the values of various constants. I would
appreciate suggestions on appropriate values for a site with 64 serial lines
(no, we don't have 64 users at one time), 1 Mb of RAM, and two RP06s. I am
particularly interested in NBUF, NPROC, NINODE, CMAPSIZ, SMAPSIZ, NCALL, and
NTEXT. The manual claims a value of 50 for [CS]MAPSIZ is enough, but I wonder.
We have 15 Mb of swap, is that reasonable?
Also, since I'll probably want to increase some buffers until I run out of
room, what's the maximum that data+bss should be? From my limited knowledge
I expect the top mapping register to be used for the I/O page, leaving 56Kb
for kernel data. Are there other considerations I should be aware of?
Thanks in advance.
--
Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!philphil@amd70.UUCP (Phil Ngai) (01/21/84)
One approach which just occurred to me is that instead of using "formulas"
which other sites have found to be useful, I can run pstat.
I am somewhat ashamed to admit I only discovered pstat a few days ago. I've
been having fun with it, it tells me lots of things I could only have
guessed about before.
I've set up cron to run pstat in all its flavors every 15 minutes.
After a few weeks of this I think I'll be able to tune V7 with confidence.
I do appreciate all the help I've gotten. Thank you, everyone.
--
Phil Ngai (408) 988-7777 {ucbvax,decwrl,ihnp4,allegra,intelca}!amd70!phil