Matthew Dillon wrote:
> Nonsense. An email proxy is not designed to use up all the machines
> resources and then gracefully back down when the machine tells it to
> stop. Nobody in their right mind runs a high volume service without
> putting hard limit on the number of connections it serves simultaniously,
> especially not in the email world.
Matt. I think you've misread what I wrote. The types of processes I am
talking about simply preallocate a configurable amount of memory as one
of the first things they do (including connection limits, etc., and then
never allocate any further memory).
With an overcommit they're not allowed to have what they want to make
certain guarantees. The OS will kill them in the future if it's doesn't
have the memory that they were asking for. I want these applications to
exit by themselves if the malloc fails. Am I wrong here? With overcommit
malloc doesn't fail, but the application will be killed by the OS in the
future if it doesn't thave the physical memory OS was asking in the
first place. I don't want that.
>
And for applications that can't afford the slow down due to swapping,
such as real time, or near real time applications? What do we do then?
Back to the drawing board?
> just failing, which means that it's an EASY problem for any
> sysadmin to tune. If you have misconfigured the program and it is
> giving you trouble, don't blame overcommit. Blame yourself for
> misconfiguring the program.
The program is not misconfigured, the OS is not giving it what it wants
by design: physical memory. Sorry. A swap file is not a solution.
>
> Having the OS deny memory to any application on a whim, and hoping that
> that application will actually *handle* that denial gracefully, is
> a pipe dream. As I said, you only see that sort of software in
It will handle it gracefully. It will exit if malloc fails, not be randomly
killed at some point in the future by the OS. That's all I want.