Hi,
On Wed, Dec 23, 2020 at 12:59 AM frank picabia <fpicabia@gmail.com> wrote:
>
>
> 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
largerRAM. On the next reboot this will free up about 1.6 GB RAM. It might help with a little wiggle room until we
knowmore about the other issue which seems to limit us to 1/2 our RAM.
I'm not sure, but the kernel parameter vm.zone_reclaim_mode and/or
NUMA memory interleaving may have an effect.
regards,
>
>
> On Mon, Dec 21, 2020 at 9:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> frank picabia <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
--
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com