lkml.org 
[lkml]   [2000]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Avoiding OOM on overcommit...?
David Whysong <dwhysong@physics.ucsb.edu>:
> On Mon, 20 Mar 2000, Jesse Pollard wrote:
> >On Mon, 20 Mar 2000, Horst von Brand wrote:
> >>Jesse Pollard <pollard@tomcat.admin.navo.hpc.mil> said:
> >>
> >>[...]
> >>
> >>> Without overcommit:
> >>> You can support 100 simultaneous connections, with full saturation of
> >>> each server, with no failures.
> >>>
> >>> Result: happy customers, happy management, maybe even a raise.
> >>
> >>Management nagging about supporting more pages, worried by waste of several
> >>Gb of disk that has never, ever been touched. System is sluggish, needs
> >>constant tweaking of "resource allocation quotas" as applications crash,
> >>even there are resources available. Seriously consider firing inept
> >>sysadmin.
> >
> >Disk space is cheap.
>
> And completely orthogonal to overcommit. You put the same disk space on
> the overcommitted machine and it will work fine.

NOPE - runaway memory allocators can still cause OOM crashes.

> >System is no more sluggish than currently, and is much more reliable.
>
> Yes, because you added more memory.

NOPE - additional swap space does not make it more sluggish in and of itself.
I guaranteed the space that is allocated to processes. If the processes don't
use it, there is no additional overhead. If the processes DO use it then they
won't be aborted by OOM conditions.

If you prefer a crash to degraded performance, you are welcome to it. I want
a way to control it.

> The correct solution to OOM situations is not to turn off overcommit. The
> correct solution is to put more memory in the machine.

With the current state of Linux, no matter how much memory you put, you
will still get OOM situation whenever processes want more memory than
you have. You can't avoid it. You can't prevent it. You can't control it.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil

Any opinions expressed are solely my own.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.034 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site