Date: Sat, 18 Dec 2010 10:56:49 -0700 From: Michael Loftis <mloftis@wgops.com> To: George Mamalakis <mamalos@eng.auth.gr> Cc: Kostik Belousov <kostikbel@gmail.com>, stable <stable@freebsd.org> Subject: Re: vm.swap_reserved toooooo large? Message-ID: <AANLkTikehVavbMTca9L7DWCJXSR5Sii8rAsvHTJgtt6B@mail.gmail.com> In-Reply-To: <4D08DE9C.1060108@eng.auth.gr> References: <4D08A0A1.40205@eng.auth.gr> <alpine.BSF.2.00.1012151220260.10096@mail.fig.ol.no> <4D08C61C.4090006@eng.auth.gr> <20101215135143.GY33073@deviant.kiev.zoral.com.ua> <4D08DE9C.1060108@eng.auth.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 15, 2010 at 8:28 AM, George Mamalakis <mamalos@eng.auth.gr> wrote: > where one can see that pid 1544 was killed before 2864, which is the process > that caused all this mess. Yes, I know that I should use limits so as not to > allow such things to happen, but on the other hand, if a malicious user > causes such a situation he/she may gain access to information through > core-dumps on root processes, AND cause DoS attacks. If it were for me, I > would sort all processes based on their memory consumption, and start by > killing those that have the highest value (top-bottom) that are NOT owned by > root (just a thought, without thinking about it too much), so as to prevent > such situations from happening. > Which on most large, multi-user systems, will actually end up being your database processes most of the time. Once in a while it might get lucky and clobber the right process but usually in my experience that algorithm does not work. Neither does "most CPU using" and in fact, most CPU using usually ends up worse because your long lived daemons (Apache, MySQL, mail server, etc) become the primary targets. As was said by someone else, the system killing mechanism should be a last resort, per user resource limits should be your first lines of defense, and process limits, things of that nature.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikehVavbMTca9L7DWCJXSR5Sii8rAsvHTJgtt6B>