Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
To: John Nemeth <email@example.com>
From: Daniel C. Sobral <firstname.lastname@example.org>
Date: 07/15/1999 13:35:01
John Nemeth wrote:
> On one system I administrate, the largest process is typically
> rpc.nisd (the NIS+ server daemon). Killing that process would be a
> bad thing (TM). You're talking about killing random processes. This
> is no way to run a system. It is not possible for any arbitrary
> decision to always hit the correct process. That is a decision that
> must be made by a competent admin. This is the biggest argument
> against overcommit: there is no way to gracefully recover from an
> out of memory situation, and that makes for an unreliable system.
If you run out of memory, it is either a misconfigured system, or a
runaway program. If a program is runaway, then:
1) It is larger than your typical rpc.nisd.
2) You cannot tell the system a priori to kill it, because you don't
know about it (or else, you wouldn't be running it in first place).
A system running in overcommit assumes that you have it correctly
configured so it will *not* run out of memory under normal
conditions. This happens to be the same assumption Unix does.
Daniel C. Sobral (8-DCS)
"Would you like to go out with me?"
"I'd love to."
"Oh, well, n... err... would you?... ahh... huh... what do I do