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 |
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? |
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) |