Horton

Re: Estimating HugePages Requirements?

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: bossartn@amazon.com
Cc: tgl@sss.pgh.pa.us, robertmhaas@gmail.com, michael@paquier.xyz, masao.fujii@oss.nttdata.com, pryzby@telsasoft.com, andres@anarazel.de, magnus@hagander.net, mark.dilger@enterprisedb.com, don@seiler.us, pgsql-hackers@postgresql.org
Date: 2021-09-14T00:49:36Z
Lists: pgsql-hackers 
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.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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.