Horton

Re: Estimating HugePages Requirements?

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: "Bossart, Nathan" <bossartn@amazon.com>
Cc: Michael Paquier <michael@paquier.xyz>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, tgl@sss.pgh.pa.us, robertmhaas@gmail.com, masao.fujii@oss.nttdata.com, andres@anarazel.de, magnus@hagander.net, mark.dilger@enterprisedb.com, don@seiler.us, pgsql-hackers@postgresql.org
Date: 2021-09-16T17:14:27Z
Lists: pgsql-hackers 
+ * and the hugepage-related mmap flags to use into *mmap_flags.  If huge pages
+ * is not supported, *hugepagesize and *mmap_flags will be set to 0.

nitpick: *are* not supported, as you say elsewhere.

+                       gettext_noop("Shows the number of huge pages needed for the main shared memory area."),

Maybe this was already discussed, but "main" could be misleading.

To me that sounds like there might be huge pages needed for something other
than the "main" area and the reported value might turn out to be inadequate,
(which is exactly the issue these patch are trying to address).

In particular, this sounds like it's just going to report
shared_buffers/huge_page_size (since shared buffers is usually the "main" use
of shared memory) - rather than reporting the size of the entire shared memory
in units of huge_pages.

-- 
Justin

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.