Horton

Re: Estimating HugePages Requirements?

Nathan Bossart <bossartn@amazon.com>

View thread View on postgr.es
From: "Bossart, Nathan" <bossartn@amazon.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, 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-14T00:30:22Z
Lists: pgsql-hackers 
On 9/13/21, 1:25 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Seems like "huge_pages_needed_for_shared_memory" would be sufficient.

I think we are down to either shared_memory_size_in_huge_pages or
huge_pages_needed_for_shared_memory.  Robert's argument against
huge_pages_needed_for_shared_memory was that it might sound like only
part of shared memory uses huge pages and we're only giving the number
required for that.  Speaking of which, isn't that technically true?
For shared_memory_size_in_huge_pages, the intent is to make it sound
like we are providing shared_memory_size in terms of the huge page
size, but I think it could also be interpreted as "the amount of
shared memory that is currently stored in huge pages."

I personally lean towards huge_pages_needed_for_shared_memory because
it feels the most clear and direct to me.  I'm not vehemently opposed
to shared_memory_size_in_huge_pages, though.  I don't think either one
is too misleading.

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.