Making 3B2/310 faster

Steve Paddock paddock at mybest6.UUCP
Fri Oct 21 10:58:37 AEST 1988


In article <260 at beartrk.UUCP> clp at beartrk.UUCP (Charlie Pilzer) writes:
>I have a client who is using a 3B2/310 for a relatively small (<10000 records)
>database.  There are some users who are complaining that the machine is too
>slow and would like to enhance the performance.  But they would like to do it
>inexpensively if possible.

I'd consider:

1. Running sar to verify that the disk is the bottleneck.  If it is,
try adding memory and devoting more than default memory to disk
buffers.  Overall, I've found that a 14mhz 4meg 310 is a vast improvement 
over stock; even at stock 10mhz, NBUF  = 1100 in /etc/master.d/kernel does 
very good things for disk intensive operations with 4mb RAM.  Also consider 
that you can upgrade to 3MB to mitigate cost.  Another tool (in 3.n, at least)
for checking on memory/swap activity is swap -l.

2. Lowering priority of background jobs and uucp jobs by writing "nice -20 xxx"
wrappers for uuxqt and uusched and by lowering priority of lpsched in
/etc/rc.d/lp.

3. Use the undocumented feature of putting pri=n as the first thing
in the gcos field of /etc/passwd.  This causes the user to start with
an elevated or reduced nice value (see ps -el output to verify both 2. and 3.)
I nice nuucp down to 39 with no problems and significant performance 
improvements.  By the same token, enhance the priority of the complaining
users.

4. Consider increasing the clock speed to 14mhz.  Some folks have had terrible
luck with this - unexplained disk errors and surprises, others have had
success.  The ambient temperature is a critical factor even when the
motherboard is qualified for this upgrade.

5. Using sar again, be sure that the kernel is as small as possible where
you don't need the configuration.

6. I haven't seen that two drives makes a real difference in performance; 
nor have I seen a correlation between the placement of /usr on the second
drive and improved performance, manual notwithstanding.

7. Do consider backing up the partitions to tape, and either using
mkfs to rebuild an orderly file system or doing rm * followed by fsck -s
to rebuild the free list.  There is a command in /etc, compress, I believe,
which will automate some of this for you.

Disclaimer: I work for AT&T, however these are my opinions.  I'm 
sure we disagree on many things, but I am fond of the 310, and was
before I was hired.

Steve
-- 
------------------------------------------------------------------------------
Steve Paddock  uunet!bigtex!mybest!paddock
               ut-emx!mybest!paddock 
               {attmail|gbsic5|bscaus}!uhous1!paddock



More information about the Comp.sys.att mailing list