Re: Estimating HugePages Requirements? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: Estimating HugePages Requirements?
Date
Msg-id C7F4DD29-549E-4EA3-87DA-D08D48B57B03@amazon.com
Whole thread Raw
In response to Re: Estimating HugePages Requirements?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Estimating HugePages Requirements?  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On 9/2/21, 10:12 PM, "Kyotaro Horiguchi" <horikyota.ntt@gmail.com> wrote:
> By the way I noticed that postgres -C huge_page_size shows 0, which I
> think should have the number used for the calculation if we show
> huge_page_required.

I would agree with this if huge_page_size was a runtime-computed GUC,
but since it's intended for users to explicitly request the huge page
size, it might be slightly confusing.  Perhaps another option would be
to create a new GUC for this.  Or maybe it's enough to note that the
value will be changed from 0 at runtime if huge pages are supported.
In any case, it might be best to handle this separately.

> I noticed that postgres -C shared_memory_size showed 137 (= 144703488)
> whereas the error message above showed 148897792 bytes (142MB). So it
> seems that something is forgotten while calculating
> shared_memory_size.  As the consequence, launching postgres setting
> huge_pages_required (69 pages) as vm.nr_hugepages ended up in the
> "could not map anonymous shared memory" error.

Hm.  I'm not seeing this with the v5 patch set, so maybe I
inadvertently fixed it already.  Can you check this again with v5?

Nathan


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pgsql: Set the volatility of the timestamptz version of date_bin() back
Next
From: Andres Freund
Date:
Subject: Re: prevent immature WAL streaming