Re: Estimating HugePages Requirements?

Nathan Bossart <bossartn@amazon.com>

From: "Bossart, Nathan" <bossartn@amazon.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>, "robertmhaas@gmail.com" <robertmhaas@gmail.com>, "michael@paquier.xyz" <michael@paquier.xyz>, "masao.fujii@oss.nttdata.com" <masao.fujii@oss.nttdata.com>, "pryzby@telsasoft.com" <pryzby@telsasoft.com>, "andres@anarazel.de" <andres@anarazel.de>, "magnus@hagander.net" <magnus@hagander.net>, "mark.dilger@enterprisedb.com" <mark.dilger@enterprisedb.com>, "don@seiler.us" <don@seiler.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-09-14T18:00:44Z
Lists: pgsql-hackers
On 9/13/21, 5:49 PM, "Kyotaro Horiguchi" <horikyota.ntt@gmail.com> wrote:
> At Tue, 14 Sep 2021 00:30:22 +0000, "Bossart, Nathan" <bossartn@amazon.com> wrote in
>> 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.
>
> I like 'in' slightly than 'for' in this context. I stand by Michael
> that that name looks somewhat too long especially considering that
> that name won't be completed on shell command lines, but won't fight
> it, too.  On the other hand the full-spelled name can be thought as
> one can spell it out from memory easily than a name halfway shortened.

I think I see more support for shared_memory_size_in_huge_pages than
for huge_pages_needed_for_shared_memory at the moment.  I'll update
the patch set in the next day or two to use
shared_memory_size_in_huge_pages unless something changes in the
meantime.

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.