From: | Ahsan Ali <ali95695(at)gmail(dot)com> |
---|---|
To: | John R Pierce <pierce(at)hogranch(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: LOG: could not fork new process for connection: Cannot allocate memory |
Date: | 2016-08-26 00:45:12 |
Message-ID: | CAGot2LXQ+1f9LAvKAffCEnqZWVuzTyR9eKP_cAbcO_ZLH3fCGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
we have a pooling on the application level. however we never had this
issues before this start happning since last couple of days in past we had
over 2300 sessions but no issues.
On Thu, Aug 25, 2016 at 5:29 PM, John R Pierce <pierce(at)hogranch(dot)com> wrote:
> On 8/25/2016 5:10 PM, Ahsan Ali wrote:
>
>> yes it is older however we do apply security patches now a then.
>>
>
> redhat doesn't really support mixing packages from different releases,
> they only test things with all packages from the same snapshot. "yum
> update" should bring the whole system up to current.
>
>
> regarding max connection its the application design however it does not
>> have that many active session. postgres=# select count(*) from
>> pg_stat_activity;
>> count
>> -------
>> 1818
>>
>
> so there were 1818 postgres client processes at the time it coudln't
> create a new process. thats certainly a larger number than I've ever
> run. if I have client software that has lots and lots of idle
> connections, I use a connection pooler like pgbouncer, in transaction mode.
>
> --
> john r pierce, recycling bits in santa cruz
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
From | Date | Subject | |
---|---|---|---|
Next Message | Theron Luhn | 2016-08-26 02:44:12 | Re: Understanding Postgres Memory Usage |
Previous Message | John R Pierce | 2016-08-26 00:29:39 | Re: LOG: could not fork new process for connection: Cannot allocate memory |