pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: frank picabia <fpicabia@gmail.com>
To: pgsql-admin@postgresql.org
Subject: Re: Error: "could not fork new process for connection: Cannot allocate memory"
Date: Mon, 21 Dec 2020 14:34:58 +0100
Message-ID: <fce391ac5b00b86921e680ebd37eaa802e51dd39.camel@cybertec.at> (raw)
In-Reply-To: <CA+AKB6F6EGnLPFDqm1kcPtyeRWyY92vbfQk-3uFVbrERYu+PJg@mail.gmail.com>
References: <CA+AKB6F6EGnLPFDqm1kcPtyeRWyY92vbfQk-3uFVbrERYu+PJg@mail.gmail.com>

On Mon, 2020-12-21 at 09:17 -0400, frank picabia wrote:
> This error occurred a couple of days ago and it is unlikely to repeat as
> it was a series of exams being done in moodle with over 500 students.
> However I'd like to tune Postgres to see if it can be prevented.
> 
> First of all, we did not run out of memory within the OS.  This system is monitored by cacti and
> Real Used memory never exceeded 30 GB on a server having 64 GB ram plus some swap.
> 
> I can also see in the messages log, the Linux kernel OOM killer was never triggered.
> 
> The postgres user running the DB has no ulimits on memory which might apply.
> 
> Here is the entry in the Postgres log:
> 
> <2020-12-19 13:19:29 GMT>LOG: could not fork new process for connection: Cannot allocate memory
> TopMemoryContext: 136704 total in 13 blocks; 6688 free (4 chunks); 130016 used
> smgr relation table: 24576 total in 2 blocks; 13904 free (4 chunks); 10672 used
> TopTransactionContext: 8192 total in 1 blocks; 6152 free (5 chunks); 2040 used
> <2020-12-19 13:19:29 GMT>LOG: could not fork new process for connection: Cannot allocate memory
> TransactionAbortContext: 32768 total in 1 blocks; 32728 free (0 chunks); 40 used
> Portal hash: 8192 total in 1 blocks; 1672 free (0 chunks); 6520 used
> PortalMemory: 0 total in 0 blocks; 0 free (0 chunks); 0 used
> 
> My conclusion is this memory error must be related to limits within Postgres tunables, or perhaps
>  something like SHM memory, which we have not set up in the sysctl.conf , so this is just a default amount.
> 
> The values we have in postgres.conf are mostly suggested by pgtune script.  The one exception being
>  max_connections=500, which was increased to try to avoid bottlenecks being reached with Apache client
>  numbers, and gradually over time as we saw we still had lots of memory available with a higher connection limit.
> 
> Which tunables do you need to see?

You probably have to increase the operating system limit for open files
for the "postgres" user (ulimit -n).

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com






view thread (12+ messages)  latest in thread

Message-ID: <fce391ac5b00b86921e680ebd37eaa802e51dd39.camel@cybertec.at>
Permalink:  ../fce391ac5b00b86921e680ebd37eaa802e51dd39.camel@cybertec.at/
Also on:    postgresql.org/message-id/fce391ac5b00b86921e680ebd37eaa802e51dd39.camel@cybertec.at

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: laurenz.albe@cybertec.at, fpicabia@gmail.com
  Subject: Re: Error: "could not fork new process for connection: Cannot allocate memory"
  In-Reply-To: <fce391ac5b00b86921e680ebd37eaa802e51dd39.camel@cybertec.at>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox