NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/question/13033

Internet Message Format | 1992-11-07 | 3.6 KB

Xref: sparky comp.unix.questions:13033 comp.unix.sysv386:16290 comp.unix.sys5.r4:448 comp.unix.wizards:4553
Path: sparky!uunet!gatech!paladin.american.edu!news.univie.ac.at!hp4at!mcsun!uknet!dsbc!mbm
From: [e-mail] (Malcolm Mladenovic)
Newsgroups: comp.unix.questions,comp.unix.sysv386,comp.unix.sys5.r4,comp.unix.wizards
Subject: Re: Unix System Crashing!! Why?
Message-ID: <[e-mail]>
Date: 6 Nov 92 14:29:02 GMT
References: <[e-mail]> <[e-mail]>
Followup-To: comp.unix.sys5.r4
Organization: ICL, Bracknell, UK
Lines: 62

In article <[e-mail]> [e-mail] (Al Von Ruff) writes:
>In article <[e-mail]> [e-mail] (neal.l.leitner) writes:
>>
>>I have been having a problem with my Unix machine crashing every once in
>>a while.  I was hoping someone could shed some light on the subject.
>>[out of msg blocks on an svr4/i486 system]

>You have run out of STREAMS resources. There are two possible reasons
>for your problem:
>
>1) strthresh is tuned too low for your system use. If your machine
>   crashes at approximately the same time of day (i.e: during backups,
>   while sending/receiving news, during high UUCP traffic, running heavy
>   networking loads), then this is probably the case. strthresh is a
>   kernel tunable which designates the maximum number of bytes which
>   the STREAMS subsystem is allowed to use. This parameter has a
>   notoriously low default setting (around 2 Megabytes). I would recommend
>   setting strthresh to a value of 50 percent of physical memory.

This seems an unnecessarily high a value for large configurations - the machine
that I'm posting from has strthresh set to 4MB.  It is a dual processor sparc
running svr4 with 128MB of physical memory.  The machine is regularly running
with large amounts of networking traffic but no STREAMS resources problems.
This ought to be sufficient unless you are running with many TCP connections
doing bulk data transfer at the same time.  [It doesn't actually do any harm
to have a large value, if you do have a problem it will increase the length
of time the system stays up, though performance will degrade over time since
less and less memory will be available for the buffer cache and other uses.]

However,

>2) You have a STREAMS memory leak. If your machine crashes at approximately
>   the same uptime value (for instance: after 4 days of run time), then this
>   is probably the case. In this case, you can't do anything except report
>   the bug to your vendor. We have found and plugged a number of STREAMS leaks
>   in our product - your implementation may still contain these leaks.

this is only since we fixed a number of these.  We did have problems prior to
that.   It is possible to get an idea of the behaviour of the STREAMS subsystem
with respect to memory by checking the value of the kernel variable Strcount.
This is the counter that strthresh is a limit on.

# crash
....
> od -h Strcount
aaaaaaaa: vvvvvvvv
> od -h strthresh
bbbbbbbb: wwwwwwww
> q
#

will give you some idea of the situation.  If Strcount increases over time
with no corresponding change in the system workload you probably have a
memory leak in either the STREAMS subsystem itself or in one of the STREAMS
modules or drivers.   If this is the case you need to report the problem
to your vendor.  It may also aloow you to do planned, clean reloads at a more
convenient time than just when the system locks up.

Note: I have set followups to only comp.unix.sys5.r4 since my comments are
specific to that version and are not limited to the [34]86-based platforms.

-Malcolm