Path: utzoo!attcan!ncrcan!hcr!david
From: david@hcr.uucp (David Fiander)
Newsgroups: comp.unix.i386
Subject: Re: problems with 2 drives under 386/ix 2.0.1, and a TCP/IP problem
Message-ID: <1989Nov24.173432.7136@hcr.uucp>
Date: 24 Nov 89 17:34:32 GMT
References: <1989Nov14.175913.7840@antel.uucp> <LARRY.89Nov22130745@focsys.UUCP>
Reply-To: david@zeus.UUCP (David Fiander)
Organization: HCR Corporation, Toronto
Lines: 55

In article <LARRY.89Nov22130745@focsys.UUCP> larry@focsys.UUCP (Larry Williamson) writes:
>
>Your list (edited)...
>
>   		 alloc	 inuse	   total     max    fail
>   dblock class:
>       1 (  16)	   128	    30	   41906      32       0
>       2 (  64)	   128	    17	  214582     115      26  <<<<***
>       3 ( 128)	   128	   108	   25676     115    9001  <<<<***
>       4 ( 256)	   128	     0	   11969       8       0
>
>shows some failures. These are not good.

Failures, of themselves are not bad, but at least the system no
longer panics when a dblock allocation request fails, which it does
on release 1.0.6

>
>My strategy has been, double the number of allocated dblock classes
>until I get no more failures. So in your case, I would double NBLK64
>and NBLK128 each to 256. If failures continue to show up, increase
>them again. Also, watch for failures in the streams and queues.
>
>Our two 2.0.2 systems are set up like this...
>
>		 alloc	 inuse	   total     max    fail
>streams:	    96	    40	     304      53       0
>queues: 	   512	   216	    1702     294       0
>mblocks: 	  3270	   735	 4625499     969       0
>dblocks: 	  2616	   735	 3954806     969       0
>dblock class:
>    0 (   4)	   256	     1	  138298       7       0
>    1 (  16)	   256	    26	  560779     130       0
>    2 (  64)	  1024	   601	 3061270     819       0
>    3 ( 128)	   512	   104	   47186     148       0
>    4 ( 256)	   256	     0	   60700     123       0
>    5 ( 512)	   128	     0	   26377      40       0
>    6 (1024)	    64	     0	   23847      11       0
>    7 (2048)	    64	     3	   36349       8       0
>    8 (4096)	    56	     0	       0       0       0
>
>dblock 64 seems to be our biggest headache. I see from this list it is
>getting close to overflowing again.
>
>It has been two days since I lasted booted this machine.

The problem is that there is (at least one) memory leak in the
kernel.  Under certain fairly common circumstances, the kernel will
forget about a dblock that it has allocated but no longer needs and
just drop it on the floor.  We saw this problem in 1.0.6, and gave
Interactive a fix for it.  Ask them.

David J. Fiander,
Networking Group,
HCR Corporation.