Matthew Wakeling wrote:
On Thu, 28 Aug 2008, Steve Atkins wrote:
Probably the best solution is to just tell the kernel somehow to
never kill the postmaster.
Or configure adequate swap space?
Oh yes, that's very important. However, that gives the machine the
opportunity to thrash.
No, that's where the whole argument for allowing overcommitted memory falls
flat.
The entire argument for allowing overcommitted memory hinges on the fact that
processes *won't use the memory*. If they use it, then overcommitting causes
problems everywhere, such as a Postmaster getting arbitrarily killed.
If a process *doesn't* use the memory, then there's no problem with thrashing,
right?
So it never makes sense to enable overcommitted memory when Postgres, or any
server, is running.
Allocating a big, fat terabyte swap disk is ALWAYS better than allowing
overcommitted memory. If your usage is such that overcommitted memory would
never be used, then the swap disk will never be used either. If your processes
do use the memory, then your performance goes into the toilet, and you know
it's time to buy more memory or a second server, but in the mean time your
server processes at least keep running while you kill the rogue processes.
Craig
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
