CPU/MEMORY/MATH-CO
Conor P. Cahill
cpcahil at virtech.uucp
Mon Mar 11 22:05:59 AEST 1991
yeh at cs.purdue.EDU (Wei Jen Yeh) writes:
> This is my situation. I'm running Dell's 4.0 on a 386-20. It has 8mb of
>memory, and does not have cache or a 387. I usually work under X and have
>three to four xterms opened. The system gets REALLY SLOW when a compilation
>is taking place. It gets even worse when lisp is running. You can count the
>characters when they are displayed on the screen! So, the question is,
>how do I upgrade my system? A faster machine, more memory, or a math-co?
NOTE: This response deals mostly in System V R3.2, not 4.0. However, the
work should be verry similar, if not the same, under 4.0.
Instead of asking the net for a "general" answer, why not see for yourself
what the problems are. Run a couple of SAR reports while the system
is running "REALLY SLOW" to see if you can determine why it is slow.
The two main reports for you to look at are:
1. the standard report (system utilization report)
% sar 5 5
virtech virtech 3.2 2 i386 03/11/91
06:44:04 %usr %sys %wio %idle
06:44:09 1 4 0 95
06:44:14 1 4 0 95
06:44:19 1 4 0 95
06:44:24 1 4 0 95
06:44:29 0 4 0 95
Average 1 4 0 95
This report shows that my system is pretty much idle. No need
for more CPU power right now. (NOTE that even unless you are
maintaining verry little idle cpu over long periods of time,
your CPU is probably enough. In other words, don't get shocked
if you see 0% idle when running this report)
2. The memory usage report
% sar -r 5 5
virtech virtech 3.2 2 i386 03/11/91
06:48:34 freemem freeswp
06:48:39 1689 64048
06:48:44 1681 64048
06:48:49 1691 64048
06:48:54 1681 64048
06:48:59 1688 64048
Average 1686 64048
This shows the amount of free memory and free swap space. The
tricky part about this report is that free memory is listed as
the number of 4K pages that are free, while free swap is the
number of 1K disp pages that are free (so I have just over 6MB
of free memory and 32MB of free swap).
This is the report that will probably show you that you are swapping
which slows down the system trememdously. If you are swapping,
get more memory. It is more then worth it.
3. The next report isn't out of SAR, but it will help you if you are
tight on memory. After running you system for a while (and having
gone through several of your REALLY SLOW episodes) run the
following:
% netstat -m
alloc inuse total max fail
streams: 512 69 689 76 0
queues: 2048 386 4010 428 0
mblocks: 4440 216 2527703 1158 0
dblocks: 3552 216 2189382 1032 0
dblock class:
0 ( 4) 512 0 59837 4 0
1 ( 16) 1024 28 275442 241 0
2 ( 64) 1024 19 1663352 679 0
3 ( 128) 512 161 79344 194 0
4 ( 256) 256 0 25611 4 0
5 ( 512) 128 8 53617 15 0
6 (1024) 32 0 30761 12 0
7 (2048) 32 0 1416 17 0
8 (4096) 32 0 2 1 0
This shows you how much STREAMS buffering you have configured.
The key to this report is that you want to have no failures and
if you are tight on memory you want to have your alloc collumn
be as close to your max as you feel comfortable. I tend to like
to keep alloc 20% above max, but I'm not tight on memory.
If I was tight on memory I would change the kernel configuration
parameters (in /etc/conf/cf.d/stune) as follows:
NSTREAM 96
NQUEUE 432
NBLK4096 2
NBLK2048 18
.... (you get the idea)
>I understand that 387 will improve the X performance (at leaset for Dell's
>stock X11R4). (That brings up another question. Is Roell's port of X11R4
The 387 does not do much for xterms on X11R4. (The server has much of it's
floating point operations removed and xterms don't need to do much in the way
of floating point). If you are doing drawings or other such FPU intensive
operations, I would recommend a 387, but it doesn't sound like you are.
--
Conor P. Cahill (703)430-9247 Virtual Technologies, Inc.
uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160
Sterling, VA 22170
More information about the Comp.unix.sysv386
mailing list