Re: PostgreSQL oom_adj postmaster process to -17

Thanks you for your response.

Database config:
shared_buffers = 8GB
temp_buffers = 32MB
work_mem = 64MB
maintenance_work_mem = 512MB
effective_cache_size = 16GB

In usual load there are not much pressure on memory, but it is possible to
have all clients start using heavy reports. They are valid requests and
could consume all memory. In this border and not likely but possible
scenario it could be useful to let OOM killer to kill client's
processes/connections but leave PostgreSQL system processes (postmaster,
writer, stat, log, streaming, ...) excluded from reach of OOM killer.

On Wed, Aug 1, 2012 at 11:48 AM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:

> Radovan Jablonovsky <radovan(dot)jablonovsky(at)replicon(dot)com> wrote:
>
> > We are running PostgreSQL version 9.1.1
>
> You should apply the latest bug fixes by updating to 9.1.4.
>
> http://www.postgresql.org/support/versioning/
>
> > with 32GB of RAM, 32GB of SWAP and during high load we could reach
> > (swap + RAM) memory limit.
>
> If you're even *starting* to swap you're doing something wrong, much
> less exhausting swap space equal to actual RAM. What is your
> configuration?
>
> http://wiki.postgresql.org/wiki/Server_Configuration
>
> While it's probably a good idea to configure the OOM killer to
> behave more sanely, we tend to ignore it in favor of ensuring that
> it never comes into play. We run about 200 databases 24/7 and I
> think I've seen it kick in about twice -- when we ran queries that
> leaked memory on each row in a big query.
>
> -Kevin
>

Radovan