From owner-freebsd-current Fri Jan 3 07:25:53 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id HAA26850 for current-outgoing; Fri, 3 Jan 1997 07:25:53 -0800 (PST) Received: from sdev.usn.blaze.net.au (sdev.usn.blaze.net.au [203.17.53.19]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id HAA26841 for ; Fri, 3 Jan 1997 07:25:48 -0800 (PST) Received: (from davidn@localhost) by sdev.usn.blaze.net.au (8.8.4/8.6.9) id CAA11405; Sat, 4 Jan 1997 02:25:26 +1100 (EST) Message-ID: Date: Sat, 4 Jan 1997 02:25:26 +1100 From: davidn@sdev.usn.blaze.net.au (David Nugent) To: grog@lemis.de (Greg Lehey) Cc: FreeBSD-current@freebsd.org (FreeBSD current users) Subject: Re: Swap leak in -current? References: <199701031349.OAA15162@freebie.lemis.de> X-Mailer: Mutt 0.54 Mime-Version: 1.0 In-Reply-To: <199701031349.OAA15162@freebie.lemis.de>; from grog@lemis.de on Jan 3, 1997 14:49:28 +0100 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk grog@lemis.de writes: > I've just failed a 'make world' for the second time after > running out of swap space. I don't understand why: it looks > like the make process is using up swap at a ridiculous rate. > Here's the scenario: Pentium 133 with 64 MB of memory, a > hungry X server using about a third of this, two swap spaces > with a total of 150 MB. Well, glad its just not me. I was about to report exactly the same thing. On a machine which about a couple of weeks ago did make world flawlessly a few times, attempting to make world dies with out of memory problems. Indeed, swap space does indeed shrink to nothing (the machine in question has 64mb of RAM and 128mb of swap! No X - just minor services, web server and cache showing ~8mb in use between them). I decided earlier this evening to also kill my current source tree and export the entire -current again, but cvs runs out of swap as well, and co reports that it can't allocate memory. Running top concurrently shows available swap space plummeting from ~70M free to none as the checkout occurs, but only if files are actually checked out (ie. no change in vm at all if the files already exist), and ^C killing cvs brings it all back. top shows that the cvs process itself doesn't seem to be consuming the memory, so the 'leak' appears to be somewhere in the vm system. (btw, it took 4 passes to finally check out the entire tree again) The problem appeared first just before Christmas. Regards, David Nugent - Unique Computing Pty Ltd - Melbourne, Australia Voice +61-3-9791-9547 Data/BBS +61-3-9792-3507 3:632/348@fidonet davidn@freebsd.org davidn@blaze.net.au http://www.blaze.net.au/~davidn/