problems with 2 drives under 386/ix 2.0.1, and a TCP/IP problem
David Fiander
david at hcr.uucp
Sat Nov 25 04:34:32 AEST 1989
In article <LARRY.89Nov22130745 at focsys.UUCP> larry at 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.
More information about the Comp.unix.i386
mailing list