Horton

Re: Estimating HugePages Requirements?

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Andres Freund <andres@anarazel.de>
Cc: Magnus Hagander <magnus@hagander.net>, Michael Paquier <michael@paquier.xyz>, Mark Dilger <mark.dilger@enterprisedb.com>, Don Seiler <don@seiler.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-08-27T20:16:40Z
Lists: pgsql-hackers

Attachments

On 8/27/21, 12:39 PM, "Andres Freund" <andres@anarazel.de> wrote:
> One thing I wonder is if this wouldn't better be dealt with in a more generic
> way. While this is the most problematic runtime computed GUC, it's not the
> only one. What if we introduced a new shared_memory_size GUC, and made
> --describe-config output it? Perhaps adding --describe-config=guc-name?
>
> I also wonder if we should output the number of hugepages needed instead of
> the "raw" bytes of shared memory. The whole business about figuring out the
> huge page size, dividing the shared memory size by that and then rounding up
> could be removed in that case. Due to huge_page_size it's not even immediately
> obvious which huge page size one should use...

I like both of these ideas.

> Can you split this into a separate commit? It feels fairy uncontroversial to
> me, so I think we could just apply it soon?

I attached a patch for just the uncontroversial part, which is
unfortunately all I have time for today.

Nathan

Commits

  1. Silence extra logging when using "postgres -C" on runtime-computed GUCs

  2. doc: Improve postgres command for shared_memory_size_in_huge_pages

  3. Introduce GUC shared_memory_size_in_huge_pages

  4. Support "postgres -C" with runtime-computed GUCs

  5. Make shared_memory_size a preset option

  6. Introduce GUC shared_memory_size

  7. Move the shared memory size calculation to its own function

  8. Add new GUC, max_worker_processes, limiting number of bgworkers.