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