Date: Wed, 14 Jul 1999 13:09:01 -0700 From: jnemeth@victoria.tc.ca (John Nemeth) To: Ben Rosengart <ben@skunk.org> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <199907142009.NAA22442@vtn1.victoria.tc.ca> In-Reply-To: Ben Rosengart <ben@skunk.org> "Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))" (Jul 14, 5:57pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 14, 5:57pm, Ben Rosengart wrote:
} On Wed, 14 Jul 1999, 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.
}
} $DEITY on a pogo stick, how many times do we have to hear the same
} hypothetical argument?
It is not hypothetical in any way. The fact that you refuse to
believe the examples given is your problem.
} Tell me, Mr. Nemeth, has this ever happened to you? Have you ever come
} *close*?
The machine in question has run out of swap, due to unforseeable
excessive memory demands. This was accompanied by processes
complaining about not being able to allocate memory and then cleaning
up after themselves. I did not see random processes being killed
because of it. That is the way things should be. From this, I can
assume that the OS doesn't overcommit. In case, you're wondering, the
OS in question is:
SunOS 5.5 Generic_103093-25 sun4u sparc
}-- End of excerpt from Ben Rosengart
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907142009.NAA22442>