From owner-freebsd-hackers Thu Oct 16 02:22:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA18710 for hackers-outgoing; Thu, 16 Oct 1997 02:22:30 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from d198-232.uoregon.edu (d198-232.uoregon.edu [128.223.198.232]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA18705 for ; Thu, 16 Oct 1997 02:22:23 -0700 (PDT) (envelope-from mini@d198-232.uoregon.edu) Received: (from mini@localhost) by d198-232.uoregon.edu (8.8.5/8.8.5) id CAA21553; Thu, 16 Oct 1997 02:22:17 -0700 (PDT) Message-ID: <19971016022216.62659@micron.mini.net> Date: Thu, 16 Oct 1997 02:22:16 -0700 From: Jonathan Mini To: Mike Smith Cc: dg@root.com, hackers@FreeBSD.ORG Subject: Re: Odd out-of-swap condition; ideas? References: <199710160114.SAA11661@implode.root.com> <199710160315.MAA00331@word.smith.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.85e In-Reply-To: <199710160315.MAA00331@word.smith.net.au>; from Mike Smith on Thu, Oct 16, 1997 at 12:45:42PM +0930 X-files: The Truth is Out There Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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 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