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...?
James Sutherland <jas88@cam.ac.uk>:
> On Mon, 20 Mar 2000 20:50:08 -0600, you 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.
>
> Still not cheap enough to throw away, unless you are Boeing.
>
> >System is no more sluggish than currently, and is much more reliable.
>
> It is slower, because of the extra overhead you have imposed on every
> memory allocation. And it is no more reliable, except in OOM
> situations - which your draconian resource quotas make MUCH more
> frequent for the users.
>
> >First, "constant tweaking" means the system was/is undersized, and the
> >accounting records justify the additional business support for expansion.
>
> Point to a system which has never passed 50% of VM in use, and your
> request will be laughed out of purchasing.

Cray YMP-8 - reached 100% several years ago. Replace by C90, C90 replaced
by dual SV1 system. SV1 system at 80%, expanding to 4 nodes.
SGI Power Challenge array - reached 90% usage in 1 year. Replaced by Origin
2000. Origin 2000 (128 node) updated when load reached 80% (with several
OOM crashes due to managements choice to overcommit) Added another 128 nodes,
and a TB of disk (30-40GB used for swap.. still overcommitted, but not as
severly). I have more.

>
> >Second, If it is determined that overcommitment is necessary, then it can
> >still be done - along with the documentation on what happens when the system
> >crashes.
>
> Overcommit does not cause system crashes; nor is it related in any way
> to user resource quotas.

Of course it is. If too many users are on one system trying to do too much
at one time the system fails. Resource quotas force the users to schedule
their work, and to cooperate with the system to accomplish the goals of
business management.

> >I've never been fired for guaranteeing system uptime.
>
> You should be, if you do so by disabling legitimate use of the system.

I didn't - legitimate use was guaranteed. Crashing the system wasn't one
of the legitimate uses. Nor was causing the failure of other users processes.

> >Obviously you don't work where uptime is counted in the thousands of dollars
> >per hour.
>
> If users are unable to perform legitimate tasks due to a "lack of
> resources", when the machine has ample resources to spare, I would
> consider the system down. I would then fire the sysadmin who
> configured it that inefficiently.

Thats just it - the system was saturated.
>
> However, if you REALLY insist on setting the system up so people can
> login and display all sorts of nice OOM error messages on an idle
> system, go ahead. I'm not stopping you.

If it were idle there would be no OOM error messages :)

> >>> If you overcommit:
> >>> You might support 100 simultaneous connections, but not full saturation
> >>> of each server, without aborting some connections or crashing the
> >>> server/system.
> >>>
> >>> Result: some unhappy customers, not so happy management, difficulty
> >>> in identifying problems, and definitely no raise.
> >>
> >>Other customers are unhappy because of long download times, NS (or
> >>whatever) crashing, not getting to the site because of (local or remote)
> >>network congestion. The "catastrophe" isn't even a blip on the sysadmin's
> >>screen.
> >
> >Yup - long download times since the system keeps crashing, forcing the
> >customer to a different site and or different company.
>
> No, the system never gets as far as crashing, because the inept
> sysadmin has already disabled it.

not worth answering.

> >If network congestion is the problem here, it is also the problem without
> >overcommit. There is no correlation there.
>
> Except people continually retrying operations which are failing due to
> a non-existent lack of resources.

already answered.

> >The catastrophe is loss of business, loss of reputation, going out of
> >business because you can't keep the customers.
>
> The customers have already gone somewhere they can actually run
> software without OOM errors.

not your site - it keeps crashing.

> >>> So you used 2G byte of swap - I know where you can by 18GB of swap for about
> >>> $300 US...
>
> So what? 0 Gb of swap is still cheaper.


-------------------------------------------------------------------------
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.047 / U:0.788 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site