From owner-freebsd-hackers Wed Oct 15 19:32:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA27425 for hackers-outgoing; Wed, 15 Oct 1997 19:32:15 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from scanner.worldgate.com (scanner.worldgate.com [198.161.84.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA27402 for ; Wed, 15 Oct 1997 19:31:49 -0700 (PDT) (envelope-from marcs@znep.com) Received: from znep.com (uucp@localhost) by scanner.worldgate.com (8.8.7/8.8.7) with UUCP id UAA15366; Wed, 15 Oct 1997 20:28:19 -0600 (MDT) Received: from localhost (marcs@localhost) by alive.znep.com (8.7.5/8.7.3) with SMTP id UAA15929; Wed, 15 Oct 1997 20:32:27 -0600 (MDT) Date: Wed, 15 Oct 1997 20:32:27 -0600 (MDT) From: Marc Slemko To: Mike Smith cc: hackers@FreeBSD.ORG Subject: Re: Odd out-of-swap condition; ideas? In-Reply-To: <199710151202.VAA00264@word.smith.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 15 Oct 1997, Mike Smith wrote: > > ** Firstly, please note that this is on a 2.2 of around February vintage; > ** if this is known-and-fixed, say no more than that and we will proceed > ** to negotiating an upgrade. > > > We have a system in the field that is showing an odd out-of-swap > condition. What's most odd is that it appears to involve a leak of > some sort, where swap remains attached to a process even though the > process doesn't appear to require it. All I can say is that I see similar things on a news server running 2.2-stable from late Auguest. 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. I'll see about checking /proc//map next time I see one to see if anything is odd there.