Horton

Re: Estimating HugePages Requirements?

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Don Seiler <don@seiler.us>, P C <puravc@gmail.com>, Magnus Hagander <magnus@hagander.net>, Julien Rouhaud <rjuju123@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Date: 2021-08-10T03:38:32Z
Lists: pgsql-hackers 
Hi,

On 2021-08-09 18:58:53 -0500, Justin Pryzby wrote:
> Define shared_buffers as the exact size to be allocated/requested from the OS
> (regardless of whether they're huge pages or not), and have postgres compute
> everything else based on that.  So shared_buffers=2GB would end up being 1950MB
> (or so) of buffer cache.  We'd have to check that after the other allocations,
> there's still at least 128kB left for the buffer cache.  Maybe we'd have to
> bump the minimum value of shared_buffers.

I don't like that. How much "other" shared memory we're going to need is
very hard to predict and depends on extensions, configuration options
like max_locks_per_transaction, max_connections to a significant
degree. This way the user ends up needing to guess at least as much as
before to get to a sensible shared_buffers.

Greetings,

Andres Freund

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.