dennis@longs.LANCE.ColoState.Edu (Dennis Miyoshi) (08/03/90)
Hello again AT&T computer folks: I have a new and exciting venture in store. Recently, I was able to add 4 MB of RAM to a 6386E system running UNIX SysV Rel 3.2.1 bringing my machine to a total of 8 MB of RAM. Wonderful. Right? Wrong. I assumed that this memory addition would enable me to execute the X-Window System Release 1.1 in a more efficient manner. No distinct difference was noticed. My question is. Is there a good set of Tunable Parameters for a machine with 8 MB of RAM? Even better. Is there a table which illustrates the Tunable Prameters for 6386E's from 2 to 64 MB? The tables that I have are included with the UNIX documentation and go up to 4 MB of RAM. Any help will be appreciated. Thanks in advance. -Dennis Miyoshi Systems Engineer and Graduate Student Again. =============================================================================== ARPA Internet: dennis@longs.lance.colostate.edu UUCP : ...ncar!boulder!ccncsu!longs.lance.colostate.edu!dennis ===============================================================================
fmcgee@cuuxb.ATT.COM (~XT6561110~Frank McGee~C23~L25~6326~) (08/11/90)
In article <8287@ccncsu.ColoState.EDU> dennis@longs.LANCE.ColoState.Edu (Dennis Miyoshi) writes: > >Hello again AT&T computer folks: > >I have a new and exciting venture in store. Recently, I was able >to add 4 MB of RAM to a 6386E system running UNIX SysV Rel 3.2.1 >bringing my machine to a total of 8 MB of RAM. Wonderful. Right? >Wrong. I assumed that this memory addition would enable me to >execute the X-Window System Release 1.1 in a more efficient manner. >No distinct difference was noticed. My question is. Is there a >good set of Tunable Parameters for a machine with 8 MB of RAM? >Even better. Is there a table which illustrates the Tunable Prameters >for 6386E's from 2 to 64 MB? The tables that I have are included with >the UNIX documentation and go up to 4 MB of RAM. More memory won't help you run Open Look faster unless you are swapping. Something else to keep in mind is that as you add memory, you might need to increase swap space. In general, swap space should be atleast equal to the amount of memory installed. Since swap space is measured in 512 byte (1/2 K) blocks, you'd need atleast 16000 blocks (8 MB) of swap space. You can find out about swap with the /etc/swap command. Here's some generic information on tuning; it's basically my interpretation of what's in Chapter 5. Beyond the guidelines for 4 MB of RAM, it's probably a better idea to evaluate your processor load, and see which tunables will help. Most of what it will do is increase your disk performance though, and that probably won't help Open Look much. Hope this helps you out, Frank McGee Entry Level Systems Support attmail!fmcgee (prefered) {att,attmail}!cuuxb!fmcgee "UNIX, Xwin, and OPEN LOOK are registered trademarks of UNIX System Laboraties, Inc., in the U.S. and other countries." ------------------ As far as performance tunables go for UNIX, they are described in great detail in Chapter 5 of the UNIX System V/386 Release 3.2.2 Operations/System Administration Guide. There are good general descriptions of the UNIX tunables and how to properly adjust them in that chapter. The ones I suggest you adjust would be : NBUF - size of the buffer cache for block devices. Most of the time it is used as disk buffers. Each block is 1024 bytes (1K). Ideally, you want to set this as high as possible within reason. For example, if you have lots of disk buffers (more than 2000) you will probably spend a sizable amount of cpu time just flushing the dirty buffers. You also don't want to set it so high that the size of your buffer cache causes the system to start swapping - you can determine the amount of free memory by running sar reports (sar reports free memory in 4K pages, so multiply by 4 and you have the number of K free). I'd recommend setting it for 1000 if you have 1 MB of RAM free, and if possible you might want to go as high as 2200. If you set it above 1000 though, you'll probably want to adjust the tunable NAUTOP, which regulates how often you flush your disk buffers (for 2200 buffers the Sysadmin Guide recommends you set it for 45). NHBUF - should be 1/4 of NBUF. NPROC - size of the process table. You need an entry in the table for every process you have running. NREGION - number of memory regions. Each process uses atleast 3 memory regions, and if it happens to use shared memory it will use more. I usually recommend that it be 4 times the size of the process table. NFILE - size of the file table. Each process uses atleast 3 files; stdin, stdout, and stderr. So NFILE should be atleast as large as 3 times NPROC, and possibly larger. NINODE - size of the i-node table, should be the same size as NFILE. NCLIST - I recommend you raise this tunable "just in case". NCLIST regulates the number of CLISTS in the kernel. CLISTs are used primarily by serial device drivers to pass data around. If you happen to run out of them, you won't get any error messages on the console since it requires free CLISTs to print them. Since most of your I/O will done over the network though (networks use streams to pass data, not CLISTs), setting it for 200 should be okay. The symptom that you are out of CLISTs is that see some users that work okay, but others don't, and if one person logs off, now another persons terminal will start working again. In general, if you run out of file table, proc table, region table, or inode table space, you will get an error message on the console saying so. In addition, you can run daily sar reports to find out how things are going, and if you need more memory, or need to do more tuning. Remember also that just blindly cranking up the tunables is a bad idea as well. If you have a process table with 1000 entries, and you only use 100, you'll be spending 90% of your time scanning an empty process table as you scan the process table. -- Frank McGee, AT&T Entry Level Systems Support attmail!fmcgee (preferred) att!cuuxb!fmcgee (those that can't reach attmail)