From owner-freebsd-stable@FreeBSD.ORG Tue Feb 15 16:11:24 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0D6316A4CE for ; Tue, 15 Feb 2005 16:11:24 +0000 (GMT) Received: from shell.reiteration.net (82-34-179-228.cable.ubr01.sout.blueyonder.co.uk [82.34.179.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D37A43D5C for ; Tue, 15 Feb 2005 16:11:24 +0000 (GMT) (envelope-from lists@reiteration.net) Received: from [127.0.0.1] (helo=reiteration.net) by shell.reiteration.net with esmtp (Exim 4.44 (FreeBSD)) id 1D15IU-000Fkf-Fc for freebsd-stable@freebsd.org; Tue, 15 Feb 2005 16:11:34 +0000 From: "John" To: freebsd-stable@freebsd.org Date: Tue, 15 Feb 2005 16:11:31 +0000 Message-Id: <20050215160134.M86208@reiteration.net> In-Reply-To: <20050215043554.GA83537@dan.emsphone.com> References: <20050215012633.M48733@reiteration.net> <20050215024139.GA97764@xor.obsecurity.org> <20050215043554.GA83537@dan.emsphone.com> X-Mailer: Open WebMail 2.50 20050106 X-OriginatingIP: 195.173.57.160 (jfm) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: lists@reiteration.net X-SA-Exim-Scanned: No (on shell.reiteration.net); SAEximRunCond expanded to false Subject: Re: swapfile being eaten by unknown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 16:11:25 -0000 On Mon, 14 Feb 2005 22:35:55 -0600, Dan Nelson wrote > In the last episode (Feb 14), Kris Kennaway said: > > On Tue, Feb 15, 2005 at 01:30:42AM +0000, John wrote: > > > Is there a way of seeing *what* program/process is eating swap. > > > There are loads of ways of seeing that it is being eaten, but so > > > far haven't found a way of knowing what eats, so can't fix the > > > problem. Can anyone enlighten me? > > > > Use ps or top, and look for the process with the huge size. This is > > not foolproof, because a process can allocate memory without using it > > (e.g. rpc.statd), but it's a place to start. If you see a process > > that is both large, and paging to/from disk, that's a better > > indication. > > To see which processes are paging: run top, hit 'm' to switch modes, > and hit 'o' then 'fault' to sort the processes by how many page > faults they are doing. This isn't completely foolproof either, > since reads from mmap()ed files count as faults as well. > Another data point - I see this in my nightly security logs: swap_pager: indefinite wait buffer: device: ad0s1f, blkno: 28190, size: 4096 maybe there's a bad block on the swap partition?? -- lists'reiteration.net