[net.unix-wizards] 4.2 System Tuning

bikki@isosvax.UUCP (Srinivas Bikkina) (10/23/84)

I am running 4.2BSD on a VAX 780 with 4 Able VMZ32N's configured as dmf32's.
Following were some of the statistics taken when the system response was awful.
I am puzzled with the very high figure (1000's) of interrupts field of vmstat.
At the time the statistics were taken there were 16 users. But, this happened
even when there are  1 or 2 users on a weekend. This situation occurs now and
then, while our normal figures for interupts are between 200-400.

<Output of vmstat 1>
 procs     memory                       page      disk  faults          cpu
 r b w   avm  fre  re at  pi  po  fr  de  sr h0 h1 x2 x3  in  sy  cs us sy id
 7 0 0  3276  947   0  2   1   0   0   0   1  5  2  0  0 529 416  30 26 72  2
 7 0 0  3276  947   6  1   0   0   0   0   0  0  2  0  01025 104  21 32 68  0
 7 0 0  3276  947   5  0   0   0   0   0   0  0  2  0  01021 108  21 37 63  0
 4 0 0  2749 1044   4  0   0   0   0   0   0  0  0  0  01020  97  19 38 62  0
 4 0 0  2749 1044   3  0   0   0   0   0   0  2  0  0  01023  90  19 43 57  0
 6 0 0  3161  950   0  0   5   0   0   0   0 24 14  0  01067  62  35 25 75  0
 5 0 0  2734 1073   1  3   1   0   0   0   0  6  8  0  01051 120  27 22 78  0

<OUTPUT of iostat 1>
      tty          hp0           hp1          cpu
 tin tout bps tps msps  bps tps msps  us ni sy id
 423  579  19   5 25.2    7   2 22.4  26  0 72  2
 957 1044   7   2 15.8   10   2 15.8  41  0 59  0
 931 1223   1   1 29.0    6   2 10.2  30  0 70  0
1019 1047  31   6 19.9   20  16 18.0   8  0 92  0
 956 1026   5   1 31.7   27  11 18.3  30  0 70  0
 967 1065   0   0  0.0    0   0  0.0  44  0 56  0
 963 1059   7   1 11.7    0   0  0.0  39  0 61  0

<OUTPUT of ps a>
  PID TT STAT  TIME COMMAND
16345 p0 S     0:11 -h -i (csh)
16415 p0 R     0:01 ps a
15372 h0 I     0:26 -u (csh)
16343 h0 S     0:00 script
16344 h0 S     0:01 script
16406 h3 I     0:02 /usr/ingres/bin/monitor CM 16406 c9 apts /usr/ingres
16407 h3 I     0:01 /usr/ingres/bin/vaxingres CP 16406 c9 apts /usr/ingres
16171 hf S     0:06 vi deb3
16050 i1 IW    0:01 mail
16411 i2 R     0:03 w
16412 i2 S     0:00 sort
16413 i2 I     0:00 more
16136 j1 S     0:17 vi rep
15369 j7 IW    0:10 vi proto.pe
16307 j9 I     0:00 make
16308 j9 I     0:00 cc -I. -DDEBUG -g xfer.c
16340 j9 R     0:23 ccom /tmp/ctm163084 /tmp/ctm163083 -Xg

I would appreciate any information on system tuning.
I will be glad to provide any more necessary information.
Please respond by mail.
Thanking you in advance,
bikki.
    ...{allegra,ihnp4,ucbvax}!arizona!asuvax!isosvax
    ...{ucbvax!hplabs,ihnp4!dual}!intelca!omovax!isosvax

irwin@uiucdcs.UUCP (10/26/84)

What does it look like with the uptime command? We have two 780s, both
have 96 ports and average 40 users during the day. Under these conditions,
if there are several background jobs running, the load average gets as
high as 15. That slows things down. You will note that ours was .86 with
6 users when I just sampled it.

  3:48am  up 2 days, 13:54,  6 users,  load average: 0.86, 0.57, 0.80

bass@dmsd.UUCP (John Bass) (10/29/84)

Since I didn't spot any upload/download/uucp/network activity in the ps
listing is smells like a floating rs232 input talking to itself or a flakey
board in the system. A floating rs232 line talking to itself also leaves
a trail of aborted logins in /usr/adm/wtmp (or it's eqiv on 4.2) ... and
simular tracks in the process accounting data ... both point to the bad line.
If it's some other board in the system ... time to plug your own metrics into
the interrupt handlers and figure out where they are coming from ...

Have fun ...
John Bass