Subject: Re: Error: "could not fork new process for connection: Cannot
 allocate memory"
To: frank picabia <fpicabia@gmail.com>
Cc: pgsql-admin@postgresql.org
References: 
 <CA+AKB6F6EGnLPFDqm1kcPtyeRWyY92vbfQk-3uFVbrERYu+PJg@mail.gmail.com>
 <fce391ac5b00b86921e680ebd37eaa802e51dd39.camel@cybertec.at>
 <492638.1608564438@sss.pgh.pa.us>
 <CA+AKB6FUXcJH32YX9UYgV749NqBFMOh270moE7izBcZt+-VyJg@mail.gmail.com>
 <CA+AKB6HxKgOvKAL8yuH7=Sc9ENs5Me4ouoGR16e9H3EdCWvKqg@mail.gmail.com>
 <574264.1608600463@sss.pgh.pa.us>
 <CA+AKB6EZHm3=c_Lddgq+PMZozbmeYy61J751-FhkuJ5ZFj7oNQ@mail.gmail.com>
From: MichaelDBA <MichaelDBA@sqlexec.com>
Message-ID: <95bf577e-f598-3ec5-0c2c-e2d1ca0d7f70@sqlexec.com>
Date: Tue, 22 Dec 2020 12:53:05 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 PostboxApp/7.0.42
MIME-Version: 1.0
In-Reply-To: 
 <CA+AKB6EZHm3=c_Lddgq+PMZozbmeYy61J751-FhkuJ5ZFj7oNQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------A87E2210CD649B0B270BB604"
Content-Language: en-US
Precedence: bulk

This is a multi-part message in MIME format.
--------------A87E2210CD649B0B270BB604
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

perhaps kernel parameters under control of vmware: shmmax/shmall.

Regards,
Michael Vitale
>
> Thanks for the responses.
>
> We'll take this up with VMware support and then if it isn't a 
> configuration issue, move it along to Redhat Linux support.
>
> It was also useful to learn cgroups default support within the kernel 
> can use up so much memory on a system with larger RAM.  On the next 
> reboot this will free up about 1.6 GB RAM.  It might help with a 
> little wiggle room until we know more about the other issue which 
> seems to limit us to 1/2 our RAM.
>
>
> On Mon, Dec 21, 2020 at 9:27 PM Tom Lane <tgl@sss.pgh.pa.us 
> <mailto:tgl@sss.pgh.pa.us>> wrote:
>
>     frank picabia <fpicabia@gmail.com <mailto:fpicabia@gmail.com>> writes:
>     > My VMware admin has come back with a graph showing memory use over
>     > the period in question.  He has looked over other indicators
>     > and there are no alarms triggered on the system.
>     > It jives with what Cacti reported.  Memory was never exhausted
>     > and used only 50% of allocated RAM at the most.
>
>     > If it's not a configuration issue in Postgres, and both internal and
>     > external tools
>     > show memory was not consumed to the point of firing off the
>     "cannot fork"
>     > error, would that mean that there is a bug in either the kernel
>     or Postgres?
>
>     [ shrug... ]  Postgres is just reporting to you that the kernel
>     wouldn't
>     perform a fork().  Since you've gone to great lengths to show that
>     Postgres isn't consuming excessive resources, either this is a
>     kernel bug
>     or you're running into some kernel-level (not Postgres) allocation
>     limit.
>     I continue to suspect the latter.  Desultory googling shows that
>     VMware
>     can be configured to enforce resource allocation limits, so maybe you
>     should be taking a hard look at your VMware settings.
>
>                             regards, tom lane
>


--------------A87E2210CD649B0B270BB604
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html theme="default" iconset="color"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body text="#000000">perhaps kernel parameters under control of 
vmware: shmmax/shmall.<br>
<br>
Regards,<br>
Michael Vitale<span></span><br>
<blockquote type="cite" 
cite="mid:CA+AKB6EZHm3=c_Lddgq+PMZozbmeYy61J751-FhkuJ5ZFj7oNQ@mail.gmail.com">
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <div dir="ltr"><br>Thanks for the responses.  <br><br>We'll take this 
up with VMware support and then if it isn't a configuration issue, move 
it along to Redhat Linux support.<br><br>It was also useful to learn 
cgroups default support within the kernel can use up so much memory on a
 system with larger RAM.  On the next reboot this will free up about 1.6
 GB RAM.  It might help with a little wiggle room until we know more 
about the other issue which seems to limit us to 1/2 our RAM.<br><br></div>
  <br>
  <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Dec
 21, 2020 at 9:27 PM Tom Lane &lt;<a href="mailto:tgl@sss.pgh.pa.us" 
moz-do-not-send="true">tgl@sss.pgh.pa.us</a>&gt; wrote:<br></div><blockquote
 class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px 
solid rgb(204,204,204);padding-left:1ex">frank picabia &lt;<a 
href="mailto:fpicabia@gmail.com" target="_blank" moz-do-not-send="true">fpicabia@gmail.com</a>&gt;
 writes:<br>
&gt; My VMware admin has come back with a graph showing memory use over<br>
&gt; the period in question.  He has looked over other indicators<br>
&gt; and there are no alarms triggered on the system.<br>
&gt; It jives with what Cacti reported.  Memory was never exhausted<br>
&gt; and used only 50% of allocated RAM at the most.<br>
<br>
&gt; If it's not a configuration issue in Postgres, and both internal 
and<br>
&gt; external tools<br>
&gt; show memory was not consumed to the point of firing off the "cannot
 fork"<br>
&gt; error, would that mean that there is a bug in either the kernel or 
Postgres?<br>
<br>
[ shrug... ]  Postgres is just reporting to you that the kernel wouldn't<br>
perform a fork().  Since you've gone to great lengths to show that<br>
Postgres isn't consuming excessive resources, either this is a kernel 
bug<br>
or you're running into some kernel-level (not Postgres) allocation 
limit.<br>
I continue to suspect the latter.  Desultory googling shows that VMware<br>
can be configured to enforce resource allocation limits, so maybe you<br>
should be taking a hard look at your VMware settings.<br>
<br>
                        regards, tom lane<br></blockquote></div>
</blockquote>
<br>
</body></html>

--------------A87E2210CD649B0B270BB604--