From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Radovan Jablonovsky <radovan(dot)jablonovsky(at)replicon(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-admin <pgsql-admin(at)postgresql(dot)org> |
Subject: | Re: PostgreSQL oom_adj postmaster process to -17 |
Date: | 2012-08-03 20:05:25 |
Message-ID: | CAOR=d=0g78DvJUMPvEF5894x+gvR=VBnvLQ6t6fP2erW0QXK0A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Fri, Aug 3, 2012 at 12:08 PM, Radovan Jablonovsky
<radovan(dot)jablonovsky(at)replicon(dot)com> wrote:
> 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.
You're only realistic solution is to either limit the incoming
connections via a connection pooler like pgbouncer or to lower your
work_mem to something smaller. What's you're current max connections
setting?
From | Date | Subject | |
---|---|---|---|
Next Message | Bryan Hinton | 2012-08-04 03:46:36 | |
Previous Message | Tom Lane | 2012-08-03 20:01:58 | Re: pg_dump on Postgres 9.1 |