Re: max_connections reached in postgres 9.3.3

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Kevin Grittner <kgrittn(at)ymail(dot)com>
Cc: "Vasudevan, Ramya" <ramya(dot)vasudevan(at)classmates(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: max_connections reached in postgres 9.3.3
Date: 2014-06-12 22:55:09
Message-ID: CAHyXU0zyZsg8TiZ7ZByiLk2kqUGS8SspcCmwceunrDt3zGXV8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Jun 12, 2014 at 3:32 PM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>
>> or something else entirely.
>
>
> It strikes me that this might be relevant:

Agreed. The stock advice to many, many problems of this sort is 'use
pgbouncer' but it can be hard to work in a lot of code bases and we
have to be careful to rule out some underlying possible contributing
factors before switching up things up to much. THP compaction in
particular has plaguing servers throughout the company I work for; we
haven't figured out OP's system went loaded all of a sudden.
Nevertheless, having a setup that can accumulate 1000's of connections
during high load events is not the way to go. Other than pgbouncer,
being very spartan with application server connection pools can bring
benefits (but can also cause problems).

merlin

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Eric Ridge 2014-06-12 23:17:05 Memory leak with CREATE TEMP TABLE ON COMMIT DROP?
Previous Message John R Pierce 2014-06-12 21:30:11 Re: Spurious Stalls