The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Al Boldi <a1426z@gawab.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Resource limits
Date: Mon, 26 Sep 2005 21:05:22 -0400	[thread overview]
Message-ID: <20050927010522.GB4522@localhost.localdomain> (raw)
In-Reply-To: <200509262326.10305.a1426z@gawab.com>

On Mon, Sep 26, 2005 at 11:26:10PM +0300, Al Boldi wrote:
> Neil Horman wrote:
> > On Mon, Sep 26, 2005 at 08:32:14PM +0300, Al Boldi wrote:
> > > Neil Horman wrote:
> > > > On Mon, Sep 26, 2005 at 05:18:17PM +0300, Al Boldi wrote:
> > > > > Rik van Riel wrote:
> > > > > > On Sun, 25 Sep 2005, Al Boldi wrote:
> > > > > > > Too many process forks and your system may crash.
> > > > > > > This can be capped with threads-max, but may lead you into a
> > > > > > > lock-out.
> > > > > > >
> > > > > > > What is needed is a soft, hard, and a special emergency limit
> > > > > > > that would allow you to use the resource for a limited time to
> > > > > > > circumvent a lock-out.
> > > > > >
> > > > > > How would you reclaim the resource after that limited time is
> > > > > > over ?  Kill processes?
> > > > >
> > > > > That's one way,  but really, the issue needs some deep thought.
> > > > > Leaving Linux exposed to a lock-out is rather frightening.
> > > >
> > > > What exactly is it that you're worried about here?
> > >
> > > Think about a DoS attack.
> >
> > Be more specific.  Are you talking about a fork bomb, a ICMP flood, what?
> 
> How would you deal with a situation where the system hit the threads-max 
> ceiling?
> 
Nominally I would log the inability to successfully create a new process/thread,
attempt to free some of my applications resources, and try again.

> > preventing resource starvation/exhaustion is often handled in a way thats
> > dovetailed to the semantics of how that resources is allocated (i.e. you
> > prevent syn-flood attacks differently than you manage excessive disk
> > usage).
> 
> The issue here is a general lack of proper kernel support for resource 
> limits.  The fork problem is just an example.
> 
Thats not really true.  As Mr. Helsley pointed out, CKRM is available to provide
a level of class based resource management if you need it. By default you can
also create a level of resource limitation with ulimits as I mentioned.  But no
matter what you do, the only way you can guarantee that a system will be able to
provide the resources your workload needs is to limit the number of resources
your workload asks for, and in the event it asks for too much, make sure it can
handle the denial of the resource gracefully.

Thanks and regards
Neil

> Thanks!
> 
> --
> Al
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *gpg keyid: 1024D / 0x92A74FA1 - http://pgp.mit.edu
 ***************************************************/

  reply	other threads:[~2005-09-27  1:03 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-25 14:12 Resource limits Al Boldi
2005-09-26  3:36 ` Rik van Riel
2005-09-26 14:18   ` Al Boldi
2005-09-26 15:56     ` Neil Horman
2005-09-26 17:32       ` Al Boldi
2005-09-26 17:51         ` Neil Horman
2005-09-26 20:26           ` Al Boldi
2005-09-27  1:05             ` Neil Horman [this message]
2005-09-27  5:08               ` Al Boldi
2005-09-27 12:08                 ` Neil Horman
2005-09-27 13:42                   ` Al Boldi
2005-09-27 14:36                     ` Neil Horman
2005-09-27 15:50                       ` Al Boldi
2005-09-27 17:25                         ` Neil Horman
2005-09-27 21:35                 ` Chandra Seetharaman
2005-09-26 12:28 ` Neil Horman
2005-09-26 14:44 ` Roger Heflin
2005-09-26 17:11   ` Alan Cox
2005-09-26 17:32     ` Al Boldi
2005-09-26 21:21     ` Roger Heflin
2005-09-27  3:50   ` Coywolf Qi Hunt
2005-09-26 19:07 ` Matthew Helsley
  -- strict thread matches above, loose matches on Subject: below --
2002-10-24 12:13 Frank Cornelis
2002-10-24 16:46 ` Randolph Bentson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050927010522.GB4522@localhost.localdomain \
    --to=nhorman@tuxdriver.com \
    --cc=a1426z@gawab.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox