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
-
Silence extra logging when using "postgres -C" on runtime-computed GUCs
- 8bbf8461a3a2 15.0 landed
-
doc: Improve postgres command for shared_memory_size_in_huge_pages
- bbd4951b73ec 15.0 landed
-
Introduce GUC shared_memory_size_in_huge_pages
- 43c1c4f65eab 15.0 landed
-
Support "postgres -C" with runtime-computed GUCs
- 0c39c292077e 15.0 landed
-
Make shared_memory_size a preset option
- 3b231596ccfc 15.0 landed
-
Introduce GUC shared_memory_size
- bd1788051b02 15.0 landed
-
Move the shared memory size calculation to its own function
- 0bd305ee1d42 15.0 landed
-
Add new GUC, max_worker_processes, limiting number of bgworkers.
- 6bc8ef0b7f1f 9.4.0 cited