Re: LOG: could not fork new process for connection: Cannot allocate memory - Mailing list pgsql-general

From Jim Nasby
Subject Re: LOG: could not fork new process for connection: Cannot allocate memory
Date
Msg-id 2a0bfd23-c0cc-7c7e-3301-0b0258c4fe55@BlueTreble.com
Whole thread Raw
In response to Re: LOG: could not fork new process for connection: Cannot allocate memory  (Ahsan Ali <ali95695@gmail.com>)
Responses Re: LOG: could not fork new process for connection: Cannot allocate memory  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
On 8/25/16 7:45 PM, Ahsan Ali wrote:

Please don't top-post; it's harder to read.
> On Thu, Aug 25, 2016 at 5:29 PM, John R Pierce <pierce@hogranch.com
> <mailto:pierce@hogranch.com>> wrote:
>     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.

While not the most ideal, people pay way too much attention to large
connection counts. It's not *that* big a deal.

> 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.

Well, if I'm reading your original post correctly, this on a server that
only has 252MB of memory, which is *very* small. Even so, according to
`free` there's 175MB cached, which should become available as necessary.

While the shared memory settings are an interesting theory, there's
nothing in 9.3 that would attempt to allocate more shared memory after
the database is started, so that can't be it.

The only thing I can think of is that someone enabled user quotas on the
system... though if that was the case I would expect it to apply to all
the existing backends as well (though, maybe there's some mode where
that doesn't happen...).

It might also be possible that Postgres is reporting the wrong error...
ISTR one or two cases in startup code where failure to allocate
something other than memory (like a socket) could result in a false
memory error in some pathological cases. If you've got debug symbols you
could try attaching to the postmaster and setting a breakpoint at
ereport and then trying to connect. You could then get a backtrace; just
don't leave the system in that state for long. (There might be a more
elegant way to do that...)
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461


pgsql-general by date:

Previous
From: Jim Nasby
Date:
Subject: Re: a column definition list is required for functions returning "record"
Next
From: Jeff Janes
Date:
Subject: Re: LOG: could not fork new process for connection: Cannot allocate memory