Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Estimating HugePages Requirements?
Date
Msg-id 4E144FAA-F3B1-42C3-9748-714ADB4BCC22@amazon.com
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  ("Bossart, Nathan" <bossartn@amazon.com>)
Responses Re: Estimating HugePages Requirements?  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 9/16/21, 10:17 AM, "Justin Pryzby" <pryzby@telsasoft.com> wrote:
> + * and the hugepage-related mmap flags to use into *mmap_flags.  If huge pages
> + * is not supported, *hugepagesize and *mmap_flags will be set to 0.
>
> nitpick: *are* not supported, as you say elsewhere.

Updated.  I think I originally chose "is" because I was referring to
Huge Pages as a singular feature, but that sounds a bit awkward, and I
don't think there's any substantial difference either way.

> +                       gettext_noop("Shows the number of huge pages needed for the main shared memory area."),
>
> Maybe this was already discussed, but "main" could be misleading.
>
> To me that sounds like there might be huge pages needed for something other
> than the "main" area and the reported value might turn out to be inadequate,
> (which is exactly the issue these patch are trying to address).
>
> In particular, this sounds like it's just going to report
> shared_buffers/huge_page_size (since shared buffers is usually the "main" use
> of shared memory) - rather than reporting the size of the entire shared memory
> in units of huge_pages.

I'm not sure I agree on this one.  The documentation for huge_pages
[0] and shared_memory_type [1] uses the same phrasing multiple times,
and the new shared_memory_size GUC uses it as well [2].  I don't see
anything in the documentation that suggests that shared_buffers is the
only thing in the main shared memory area, and the documentation for
setting up huge pages makes no mention of any extra memory that needs
to be considered, either.

Furthermore, I'm not sure what else we'd call it.  I don't think it's
accurate to suggest that it's the entirety of shared memory for the
server, as it's possible to dynamically allocate more as needed (which
IIUC won't use any explicitly allocated huge pages).

Nathan

[0] https://www.postgresql.org/docs/devel/runtime-config-resource.html#GUC-HUGE-PAGES
[1] https://www.postgresql.org/docs/devel/runtime-config-resource.html#GUC-SHARED-MEMORY-TYPE
[2] https://www.postgresql.org/docs/devel/runtime-config-preset.html#GUC-SHARED-MEMORY-SIZE


Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Possible fault with resolve column name (plpgsql)
Next
From: Sehrope Sarkuni
Date:
Subject: Re: Add jsonlog log_destination for JSON server logs