Re: Estimating HugePages Requirements?

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Don Seiler <don(at)seiler(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Estimating HugePages Requirements?
Date: 2021-08-27 20:16:40
Message-ID: 0D1645F3-ADFD-4B2F-9F34-961BDFBB881B@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On 8/27/21, 12:39 PM, "Andres Freund" <andres(at)anarazel(dot)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.

> Can you split this into a separate commit? It feels fairy uncontroversial to
> me, so I think we could just apply it soon?

I attached a patch for just the uncontroversial part, which is
unfortunately all I have time for today.

Nathan

Attachment Content-Type Size
0001-Move-the-shared-memory-size-calculation-to-its-own-f.patch application/octet-stream 7.1 KB

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Michael Paquier 2021-08-28 02:00:11 Re: Estimating HugePages Requirements?
Previous Message Andres Freund 2021-08-27 19:38:13 Re: Estimating HugePages Requirements?

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2021-08-27 20:35:16 Re: log_autovacuum in Postgres 14 -- ordering issue
Previous Message Andres Freund 2021-08-27 20:10:14 Re: Queries that should be canceled will get stuck on secure_write function