> Our -current system (about a week or two out of date, I guess, but
> similar.) is exhibiting memory leakage; it runs out of memory and
> panics after about 4 days.  We have 3-4 users average, 8-9 peak.
> We have 8 megs of "real" memory and about 35 of swap.  As time goes
> on, the swap space used goes from about 20% (fresh boot) to 50% or
> so (a day or two) to 90% (3-4 days) and then crashes at 100%.  This
> repeats.  We are using slip, but not PPP.

> Are there any known memory leaks like this?  At the end of the several
> days, there are no big processes; the total of process vm reported by
> PS may be as high as 12 megs or so; the total reported by vmstat or
> pstat -s will be in the 30's or 40's.

> The only abnormality I know of is that named is chomping around 50% of
> available CPU time for no clear reason; I'm not sure what it's refreshing,
> but it seems to spend a *lot* of time doing it.

The following item was extracted from some mail sent to
current-users on on Thu, 10 Nov 1994 12:07:34 +1100.

-- start include --
  > From: Andrew Herbert <andrew@werple.apana.org.au>
  > Message-Id: <199411100107.MAA15227@eplet.apana.org.au>
  
  There's a nasty problem with 386bsd's vm code (also present in netrel2, mach
  2.5 and even mach 3.0, I believe) where a vm_object can't be collapsed if it
  has a pager.  pagers are typically allocated to previously pager-less
  objects by the pageout daemon when memory runs short.  This inability to
  collapse objects with pagers is quite serious because pager resources
  (usually swap space) eventually run out as a result of an enormous string of
  un-collapsible vm_objects, each gobbling some amount of swap.
  
  Where does the string of shadow objects come from in the first place?  Each
  time a process forks, the object handling it's data segment (for example) is
  made into a shadow of two new objects which are given to the parent and the
  child of the fork.  When the child exits, the parent still has a shadowed
  vm_object.  If nothing in the parent has been paged-out, all is well - a
  call to vm_object_collapse() will clobber the shadow object, since no-one
  else needs it any more.  Otherwise, the problem described in the previous
  paragraph begins.
  
  I have written a program (to be run as root) that produces an vm_object-usage
  dump for a given process.  Try it on the sendmail daemon on a heavily loaded
  system and see what I mean by vm_objects not being collapsed...
-- end include --

Andrew also mentioned: "And if anyone wants a copy of the abovementioned
vm_object analyser, just drop me some mail."


Hope that helps,
Luke.

--
``When I left the monastery, it was not in pursuit of             Luke Mewburn
  scholarship, however, but in pursuit of an unparalleled     <lm@werj.com.au>
  career in crime.  It was quite a shock for me to
  discover that crime was so easy that it was boring.  [ ... ] Solving crime,
  I had belatedly discovered, was at least a hundred times more difficult than
  committing it, so I hung the sign of a half-closed eye above my door and I
  have never regretted it.''
    -- Li Kao, in Barry Hughart's 'Bridge of Birds'