From owner-freebsd-stable@FreeBSD.ORG Sat Dec 18 18:19:52 2010 Return-Path: Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 493DA106564A for ; Sat, 18 Dec 2010 18:19:52 +0000 (UTC) (envelope-from mloftis@wgops.com) Received: from mail-bw0-f48.google.com (mail-bw0-f48.google.com [209.85.214.48]) by mx1.freebsd.org (Postfix) with ESMTP id D5FA28FC18 for ; Sat, 18 Dec 2010 18:19:51 +0000 (UTC) Received: by bwz8 with SMTP id 8so1628247bwz.7 for ; Sat, 18 Dec 2010 10:19:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.126.87 with SMTP id b23mr1868495bks.203.1292695009279; Sat, 18 Dec 2010 09:56:49 -0800 (PST) Received: by 10.204.121.82 with HTTP; Sat, 18 Dec 2010 09:56:49 -0800 (PST) In-Reply-To: <4D08DE9C.1060108@eng.auth.gr> References: <4D08A0A1.40205@eng.auth.gr> <4D08C61C.4090006@eng.auth.gr> <20101215135143.GY33073@deviant.kiev.zoral.com.ua> <4D08DE9C.1060108@eng.auth.gr> Date: Sat, 18 Dec 2010 10:56:49 -0700 Message-ID: From: Michael Loftis To: George Mamalakis Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , stable Subject: Re: vm.swap_reserved toooooo large? 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: Sat, 18 Dec 2010 18:19:52 -0000 On Wed, Dec 15, 2010 at 8:28 AM, George Mamalakis 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.