Bruce Momjian wrote:
>
> Thanks. Interesting. Hard to imagine what they were thinking when they
> put this code in.
Way back in the day, when dinosaurs ruled the earth, or at least the
server room, many applications were written with rather bad memory
allocation semantics: they'd grab a bunch of memory and not necessarily use
it for anything. Typically you could specify a maximum memory
allocation amount for the program but the problem was that it would grab
exactly that amount, and it's obviously better for it to be a bit more
dynamic.
That in itself isn't a terribly bad thing ... if you have enough actual
memory to deal with it.
Problem is, back then most systems didn't have enough memory to deal
with multiple programs behaving that way.
Overcommit was designed to account for that behavior. It's not ideal at
all but it's better to have that option than not.
Overcommit isn't really necessary today because of the huge amount of
memory that you can put into a system for cheap (HP servers excluded,
they want some serious cash for memory).
--
Kevin Brown kevin@sysexperts.com