Re: Estimating HugePages Requirements?

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "robertmhaas(at)gmail(dot)com" <robertmhaas(at)gmail(dot)com>, "masao(dot)fujii(at)oss(dot)nttdata(dot)com" <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net>, "mark(dot)dilger(at)enterprisedb(dot)com" <mark(dot)dilger(at)enterprisedb(dot)com>, "don(at)seiler(dot)us" <don(at)seiler(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Estimating HugePages Requirements?
Date: 2021-09-16 21:26:56
Message-ID: 4E144FAA-F3B1-42C3-9748-714ADB4BCC22@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On 9/16/21, 10:17 AM, "Justin Pryzby" <pryzby(at)telsasoft(dot)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 Content-Type Size
v12-0001-Introduce-shared_memory_size_in_huge_pages-GUC.patch application/octet-stream 9.5 KB

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Michael Paquier 2021-09-17 02:20:30 Re: Estimating HugePages Requirements?
Previous Message Justin Pryzby 2021-09-16 17:14:27 Re: Estimating HugePages Requirements?

Browse pgsql-hackers by date

  From Date Subject
Next Message Sehrope Sarkuni 2021-09-16 21:27:20 Re: Add jsonlog log_destination for JSON server logs
Previous Message Tom Lane 2021-09-16 20:05:22 Re: Possible fault with resolve column name (plpgsql)