Horton

Re: Estimating HugePages Requirements?

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Fujii Masao <masao.fujii@oss.nttdata.com>, Justin Pryzby <pryzby@telsasoft.com>, "Andres Freund" <andres@anarazel.de>, Magnus Hagander <magnus@hagander.net>, "Mark Dilger" <mark.dilger@enterprisedb.com>, Don Seiler <don@seiler.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-09-13T18:49:16Z
Lists: pgsql-hackers 
On 9/13/21, 8:59 AM, "Robert Haas" <robertmhaas@gmail.com> wrote:
> On Fri, Sep 10, 2021 at 7:43 PM Bossart, Nathan <bossartn@amazon.com> wrote:
>> I think that's an improvement.  The only other idea I have at the
>> moment is num_huge_pages_required_for_shared_memory.
>
> Hmm, that to me sounds like maybe only part of shared memory uses huge
> pages and maybe we're just giving you the number required for that
> part. I realize that it doesn't work that way but I don't know if
> everyone will.

Yeah, I agree.  What about
huge_pages_needed_for_shared_memory_size or
huge_pages_needed_for_main_shared_memory?  I'm still not stoked about
using "required" or "needed" in the name, as it sounds like huge pages
must be allocated for the server to run, which is only true if
huge_pages=on.  I haven't thought of a better word to use, though.

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.