Date: Mon, 24 Mar 2003 17:28:44 -0800 From: David Schultz <das@FreeBSD.ORG> To: Dan Nelson <dnelson@allantgroup.com> Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Wes Peters <wes@softweyr.com>, freebsd-arch@FreeBSD.ORG Subject: Re: Patch to protect process from pageout killing Message-ID: <20030325012844.GB4406@HAL9000.homeunix.com> In-Reply-To: <20030324213519.GA63147@dan.emsphone.com> References: <200303240823.48262.wes@softweyr.com> <7019.1048523782@critter.freebsd.dk> <20030324213519.GA63147@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Dan Nelson <dnelson@allantgroup.com>: > 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. I think that's overengineering the problem. First of all, it means that on any system where RLIMIT_RSS is unlimited by default, the machine now deadlocks when it runs out of memory. Second, it is only marginally useful to go as far as specifying priorities and quotas and such on process killability. Most of the time, people can divide the processes on thier system into two categories: critical and killable. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030325012844.GB4406>