From owner-freebsd-stable@FreeBSD.ORG  Tue Apr  5 14:54:50 2011
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Delivered-To: freebsd-stable@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 151B71065673;
	Tue,  5 Apr 2011 14:54:50 +0000 (UTC)
	(envelope-from petefrench@ingresso.co.uk)
Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk
	[IPv6:2001:470:1f09:176e::3])
	by mx1.freebsd.org (Postfix) with ESMTP id D2B078FC1B;
	Tue,  5 Apr 2011 14:54:49 +0000 (UTC)
Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6]
	helo=dilbert.ticketswitch.com)
	by constantine.ingresso.co.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.73 (FreeBSD)) (envelope-from <petefrench@ingresso.co.uk>)
	id 1Q77eY-0000yp-Lf; Tue, 05 Apr 2011 15:54:46 +0100
Received: from petefrench by dilbert.ticketswitch.com with local (Exim 4.74
	(FreeBSD)) (envelope-from <petefrench@ingresso.co.uk>)
	id 1Q77eY-0001Mc-Ke; Tue, 05 Apr 2011 15:54:46 +0100
To: avg@FreeBSD.org, petefrench@ingresso.co.uk
In-Reply-To: <4D9B275B.3060000@FreeBSD.org>
Message-Id: <E1Q77eY-0001Mc-Ke@dilbert.ticketswitch.com>
From: Pete French <petefrench@ingresso.co.uk>
Date: Tue, 05 Apr 2011 15:54:46 +0100
Cc: spawk@acm.poly.edu, freebsd-stable@FreeBSD.org, freebsd@jdc.parodius.com
Subject: Re: Kernel memory leak in 8.2-PRERELEASE?
X-BeenThere: freebsd-stable@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Production branch of FreeBSD source code <freebsd-stable.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>, 
	<mailto:freebsd-stable-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-stable>
List-Post: <mailto:freebsd-stable@freebsd.org>
List-Help: <mailto:freebsd-stable-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-stable>,
	<mailto:freebsd-stable-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2011 14:54:50 -0000

> Having swap provides some cushion.  Swap kind of smooths any bursts. (And it can
> also slow things down as a side effect)

This is why I got rid of it - my application is a lot of CGI scripts. The
overload condition is that we run out of memory - and we run *way* out
of memory .... its never just a little overflow, it;s either handleable or
completely crushed. But swap makes that mre llikely to happen, because
as the processes are swapped out they run slower, take longer to
finish and thus use memory for longer.

What I saw was that as soon as any web server would start tos wap it would
swftly fall down. Without swap they stay up, but reject requests. Its a better
failure mode...

these days I run a compormise - swap on internal machines, and no swap
on customer facing ones, but lots of RAM (16 gig).

-pete.