Date: Fri, 27 Aug 2021 22:57:22 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Bossart, Nathan" <bossartn@amazon.com>,
	Andres Freund <andres@anarazel.de>,
	Magnus Hagander <magnus@hagander.net>,
	Mark Dilger <mark.dilger@enterprisedb.com>,
	Don Seiler <don@seiler.us>, pgsql-hackers@postgresql.org
Subject: Re: Estimating HugePages Requirements?
Message-ID: <20210828035722.GQ26465@telsasoft.com>
References: <92BB93C3-1AA8-4548-96F7-062C4AF09182@amazon.com>
 <20210810034205.r72j5uouynepj4f2@alap3.anarazel.de>
 <0545F7B3-70C0-4DE8-8C85-EAFE6113B7EE@amazon.com>
 <YSiKS58gSXDpj6NR@paquier.xyz>
 <CABUevEwGHcsmp4rgZdcbinZOdEs_cSCabihDvRty=0zz1H95kw@mail.gmail.com>
 <20210827184648.d3jbv73pgyccqwkz@alap3.anarazel.de>
 <071DC95B-4CA8-4D2B-BD24-1A66B3EFFE28@amazon.com>
 <20210827193813.oqo5lamvyzahs35o@alap3.anarazel.de>
 <0D1645F3-ADFD-4B2F-9F34-961BDFBB881B@amazon.com>
 <YSmYq5Z4GAf8NzxM@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YSmYq5Z4GAf8NzxM@paquier.xyz>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210828035722.GQ26465%40telsasoft.com>
Precedence: bulk

On Sat, Aug 28, 2021 at 11:00:11AM +0900, Michael Paquier wrote:
> On Fri, Aug 27, 2021 at 08:16:40PM +0000, Bossart, Nathan wrote:
> > On 8/27/21, 12:39 PM, "Andres Freund" <andres@anarazel.de> wrote:
> >> One thing I wonder is if this wouldn't better be dealt with in a more generic
> >> way. While this is the most problematic runtime computed GUC, it's not the
> >> only one. What if we introduced a new shared_memory_size GUC, and made
> >> --describe-config output it? Perhaps adding --describe-config=guc-name?
> >>
> >> I also wonder if we should output the number of hugepages needed instead of
> >> the "raw" bytes of shared memory. The whole business about figuring out the
> >> huge page size, dividing the shared memory size by that and then rounding up
> >> could be removed in that case. Due to huge_page_size it's not even immediately
> >> obvious which huge page size one should use...
> > 
> > I like both of these ideas.
> 
> That pretty much looks like -C in concept, isn't it?  Except that you
> cannot get the actual total shared memory value because we'd do this
> operation before loading shared_preload_libraries and miss any amount
> asked by extensions.  There is a problem similar when attempting to do
> postgres -C data_checksums, for example, which would output an
> incorrect value even if the cluster has data checksums enabled.

Since we don't want to try to allocate the huge pages, and we also don't want
to compute based on shared_buffers alone, did anyone consider if pg_controldata
is the right place to put this ?

It includes a lot of related stuff:

max_connections setting:              100
max_worker_processes setting:         8
 - (added in 2013: 6bc8ef0b7f1f1df3998745a66e1790e27424aa0c)
max_wal_senders setting:              10
max_prepared_xacts setting:           2
max_locks_per_xact setting:           64

I'm not sure if there's any reason these aren't also shown (?)
autovacuum_max_workers - added in 2007: e2a186b03
max_predicate_locks_per_xact - added in 2011: dafaa3efb
max_logical_replication_workers
max_replication_slots

-- 
Justin