From owner-freebsd-stable@FreeBSD.ORG Tue Apr 5 19:26:07 2011 Return-Path: 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 B7B59106566B; Tue, 5 Apr 2011 19:26:07 +0000 (UTC) (envelope-from prvs=1076fd9788=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 268E38FC1E; Tue, 5 Apr 2011 19:26:06 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 05 Apr 2011 20:15:08 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 05 Apr 2011 20:15:08 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50012794731.msg; Tue, 05 Apr 2011 20:15:08 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1076fd9788=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <38ABC8EC81164D648092640447554493@multiplay.co.uk> From: "Steven Hartland" To: , References: Date: Tue, 5 Apr 2011 20:15:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 19:26:07 -0000 ----- Original Message ----- From: "Pete French" > 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). If that's php under apache either cap maxclients so this doesn't happen or even better ditch apache and switch to something like nginx + php-fpm, much quicker much more stable solution which doesn't suddenly eat all your ram and blow-up the machine. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.