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)
d...@newsguy.com
d...@freebsd.org
"Would you like to go out with me?"
"I'd love to."
"Oh, well, n... err... would you?... ahh... huh... what do I do
next?"
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
