vm.swap_reserved toooooo large?

[Michael Loftis]

On Wed, Dec 15, 2010 at 8:28 AM, George Mamalakis <mamalos at 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.