Re: Estimating HugePages Requirements?

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Magnus Hagander <magnus(at)hagander(dot)net>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Don Seiler <don(at)seiler(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Estimating HugePages Requirements?
Date: 2021-08-30 07:29:19
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-admin pgsql-hackers

On Sat, Aug 28, 2021 at 05:36:37AM +0000, Bossart, Nathan wrote:
> Attached is a hacky attempt at adding a shared_memory_size GUC in a
> way that could be used with -C. This should include the amount of
> shared memory requested by extensions, too. As long as huge_page_size
> is nonzero, it seems easy enough to provide the number of huge pages
> needed as well.

Yes, the implementation is not good. The key thing is that by wanting
to support shared_memory_size with the -C switch of postgres, we need
to call process_shared_preload_libraries before output_config_variable.
This additionally means to call ApplyLauncherRegister() before that so
as all the bgworker slots are not taken first. Going through
_PG_init() also means that we'd better use ChangeToDataDir()

Attached is a WIP to show how the order of the operations could be
changed, as that's easier to grasp. Even if we don't do that, having
the GUC and the refactoring of CalculateShmemSize() would still be
useful, as one could just query an existing instance for an estimation
of huge pages for a cloned one.

The GUC shared_memory_size should have GUC_NOT_IN_SAMPLE and
GUC_DISALLOW_IN_FILE, with some documentation, of course. I added the
flags to the GUC, not the docs. The code setting up the GUC is not
good either. It would make sense to just have that in a small wrapper
of ipci.c, perhaps.

Attachment Content-Type Size
v2-0001-Add-shared_memory_size-GUC.patch text/plain 10.2 KB

In response to


Browse pgsql-admin by date

  From Date Subject
Next Message Ian Dauncey 2021-08-30 15:08:56 RE: vacuumlo
Previous Message andrew burns 2021-08-30 03:50:23

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2021-08-30 07:31:16 Re: replace IDENTIFY_SYSTEM code in receivelog.c with RunIdentifySystem()
Previous Message Masahiko Sawada 2021-08-30 07:06:55 Re: Skipping logical replication transactions on subscriber side