From owner-freebsd-arch Mon Mar 24 17:59:42 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6556537B401 for ; Mon, 24 Mar 2003 17:59:39 -0800 (PST) Received: from mail01.stbernard.com (mail01.stbernard.com [64.154.93.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id E442E43F85 for ; Mon, 24 Mar 2003 17:59:37 -0800 (PST) (envelope-from wes@softweyr.com) Received: from salty.rapid.stbernard.com ([192.168.4.61]) by mail01.stbernard.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 24 Mar 2003 17:59:36 -0800 From: Wes Peters Organization: Softweyr.com To: Dan Nelson , Poul-Henning Kamp Subject: Re: Patch to protect process from pageout killing Date: Mon, 24 Mar 2003 17:59:36 -0800 User-Agent: KMail/1.5 Cc: freebsd-arch@FreeBSD.ORG References: <200303240823.48262.wes@softweyr.com> <7019.1048523782@critter.freebsd.dk> <20030324213519.GA63147@dan.emsphone.com> In-Reply-To: <20030324213519.GA63147@dan.emsphone.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200303241759.36410.wes@softweyr.com> X-OriginalArrivalTime: 25 Mar 2003 01:59:36.0680 (UTC) FILETIME=[3016F680:01C2F272] X-Spam-Status: No, hits=-25.7 required=5.0 tests=AWL,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, RCVD_IN_UNCONFIRMED_DSBL,REFERENCES,REPLY_WITH_QUOTES, USER_AGENT autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Monday 24 March 2003 13:35, Dan Nelson wrote: > In the last episode (Mar 24), Poul-Henning Kamp said: > > In message <200303240823.48262.wes@softweyr.com>, Wes Peters writes: > > > As promised, here's the patch to protect a process from being > > > killed when pageout is in memory shortage. This allows a process > > > to specify that it is important enough to be skipped when pageout > > > is looking for the largest process to kill. > > > > > > My needs are simple. We make a box that is a web proxy and runs > > > from a memory disk, using flash for permanent storage. The flash > > > is mounted only when a configuration write is needed, the box > > > runs from the memory disk. We've experienced a problem at > > > certain customer sites where bind will consume a lot (~30 MB) of > > > ram and then pageout will kill the largest process, which is > > > usually either named or squid. This pretty much kills the box. > > > We'd much rather have pageout kill off some of the squid worker > > > processes, we can recover from that. > > > > > > Is this a good approach to the problem? Feedback welcome. > > > > I can certainly see the point, but I'm not sure this is the way. > > > > I am not sure that we want to use the resource limits facility for > > booleans, some of the logic sourounding the suser checks may not > > hold tight. > > How about changing the kill logic to look at RLIMIT_RSS? The process > exceeding its limit by the largest amount gets killed. That way you > can exempt certain processes by raising their limit. Set named's > limit to say 10MB, and when memory gets tight the system will see > it's exceeding its quota by 20MB and kill it first. Mostly because it's not possible to predict what named's RSS will be in any particular customer installation. The ones that raised this issue were at 32MB and stable, and took about 9 days to get there. We don't want named (or squid) to die under ANY circumstances; if the box can't run both named and squid it's effectively a brick. On the other hand, we have lots (hundreds) of other smaller processes running, any one of which is expendable and can be recovered from. Yeah, better ability to adapt to the (memory) load would be perhaps a better way to do this, but I really hate the idea of dumping named on it's head and restarting 9 days of learning just because we're getting hammered by people checking the weather and traffic before heading home. -- "Where am I, and what am I doing in this handbasket?" Wes Peters wes@softweyr.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message