Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Oct 1997 02:22:16 -0700
From:      Jonathan Mini <mini@d198-232.uoregon.edu>
To:        Mike Smith <mike@smith.net.au>
Cc:        dg@root.com, hackers@FreeBSD.ORG
Subject:   Re: Odd out-of-swap condition; ideas?
Message-ID:  <19971016022216.62659@micron.mini.net>
In-Reply-To: <199710160315.MAA00331@word.smith.net.au>; from Mike Smith on Thu, Oct 16, 1997 at 12:45:42PM %2B0930
References:  <199710160114.SAA11661@implode.root.com> <199710160315.MAA00331@word.smith.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help
Are those Linux processes using any system V shared memory? If so, it would
account for the link if processes were loosing their keys and then creating
new shared regions. It would also explain why the memory usage doesn't show up
under ps. (I have had this problem before with Linux binaries)

Mike Smith <mike@smith.net.au> stands accused of saying:
> > >At the time of that last ps listing, there were only about 40 procs in 
> > >the system total, with the display (40M) and the X server (~5M) being 
> > >the two largest.
> > >
> > >One other idea that had occurred to me; does the VSZ include the size 
> > >of the stack?
> > 
> >    Yes, but it doesn't include the space of any mmapped files.
> 
> Damn.  IDL wouldn't know what mmap() was if it jumped up and bit it.
> It might be something to do with the Linux libc allocator, but I didn't 
> think gnumalloc was that chummy with the VM system.
> 
> Mark Slemko sayeth:
> > All I can say is that I see similar things on a news server running
> > 2.2-stable from late August.
> >
> > In my case, it is a process (innfeed) that allocates and deallocates
> > large amounts of memory (perhaps a couple of gigs) over its life
> > of a couple of days.  More and more swap gets used up with no visable
> > process using it.  Killing innfeed restores it.
> >
> > Note that when innfeed is killed, it goes through a graceful shutdown
> > lasting several minutes.  During that shutdown, it free()s memory
> > as it finishes things.  The swap space used decreases in a way that
> > looks loosely proportional to the amount of memory being deallocated,
> > but ~3x the amount.  It is not a case where the swap only comes back
> > when the process completely exits.
> 
> Hmm, interesting.  This looks *very* similar.  It prettymuch rules out 
> the applications and libraries in both cases, as there's nothing in 
> common between the two.
> 
> Is it possible that there's some way in which too much swap might 
> become attached to a given extent of a process' space?  Is there any 
> way of examining the swap allocation for a given process?
> 
> mike
> 
> 

-- 
Jonathan Mini 					Ingenious Productions
Software Development				P.O. Box 5693,
						Eugene, Or. 97405




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19971016022216.62659>