On 15/12/2009 12:35 PM, Mark Williamson wrote:
> So what happened is, the above update never completed and the Postgresql
> service consumed all available memory. We had to forcefully reboot the
> machine
That means your server is misconfigured. PostgreSQL should never consume
all available memory. If it does, you have work_mem and/or
maintenance_work_mem set way too high, and you have VM overcommit
enabled in the kernel. You also have too much swap.
http://www.postgresql.org/docs/current/interactive/kernel-resources.html
http://www.network-theory.co.uk/docs/postgresql/vol3/LinuxMemoryOvercommit.html
I wouldn't be surprised if you had shared_buffers set too high as well,
and you have no ulimit set on postgresql's memory usage. All those
things add up to "fatal".
A properly configured machine should be able to survive memory
exhaustion caused by a user process fine. Disable VM overcommit, set a
ulimit on postgresql so it can't consume all memory, use a sane amount
of swap, and set sane values for work_mem and maintenance_work_mem.
> Why does Postgresql NOT have a maximum memory allowed setting? We want
> to allocate resources efficiently and cannot allow one customer to
> impact others.
It does. "man ulimit".
The operating system can enforce it much better than PostgreSQL can. If
a Pg bug was to cause Pg to go runaway or try to allocate insane amounts
of RAM, the ulimit would catch it.
I *do* think it'd be nice to have ulimit values settable via
postgresql.conf so that you didn't have to faff about editing init
scripts, though.
( TODO item? )
--
Craig Ringer
