Re: Avoiding OOM on overcommit...?

From: James Sutherland (jas88@cam.ac.uk)
Date: Tue Mar 21 2000 - 06:42:52 EST


On Mon, 20 Mar 2000 22:02:33 -0600, you wrote:

>On Mon, 20 Mar 2000, David Whysong wrote:
>>On Mon, 20 Mar 2000, Jesse Pollard wrote:
>>
>>>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.
>>>
>>>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.
>>>
>>>So you used 2G byte of swap - I know where you can by 18GB of swap for about
>>>$300 US...
>>
>>That's very misleading. In fact if you give the overcommitted system the
>>same amount of VM, it will work just fine.
>>
>>In other words, turning off overcommit isn't what saves you. You added
>>more memory!
>
>I guaranteed that the memory allocated could be used. I didn't just add
>more memory. Just adding more memory will still allow the system to fail,
>it may take longer, it may not happen as often. But it can still happen.

In EVERY case where your non-overcommit system operates correctly, my
overcommitted machine does too.

Under heavier load, there is a point where my system continues to
operate correctly but yours fails with OOM errors.

Finally, we reach a heavy overload situation, where both systems fail
with OOM errors.

Explain why you believe causing the second situation to fail
unnecessarily is an improvement.

>The quotas prevent someone from exceeding what is really alloted to the
>job. If the job exceeds that quota then something is wrong, it gives a
>control point, AND it prevents the "something wrong" from affecting the
>rest of the system.

Yes, we KNOW you want user resource quotas. You can't have them yet,
so stop talking about them - they are irrelevant here.

James.

-
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/



This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:32 EST