MIME-Version: 1.0
References: <CAJCjmtsEtKMyBxZDg3Do72fr+VVF0eVUdt1aBUctD9BVEt_LNg@mail.gmail.com>
In-Reply-To: <CAJCjmtsEtKMyBxZDg3Do72fr+VVF0eVUdt1aBUctD9BVEt_LNg@mail.gmail.com>
From: Alicja Kucharczyk <zaledwie10minut@gmail.com>
Date: Wed, 7 May 2025 14:16:49 +0200
Message-ID: <CAM=sWa5eM2_M_jqdYnU45nOuB_R=V8i8koS_hX0cAFjjSChv+w@mail.gmail.com>
Subject: Re: huge_pages=on cause could not map anonymous shared memory: Cannot
 allocate memory
To: Bogdan Siara <bogdan.siara@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000c554c906348ab541"
Archived-At: <https://www.postgresql.org/message-id/CAM%3DsWa5eM2_M_jqdYnU45nOuB_R%3DV8i8koS_hX0cAFjjSChv%2Bw%40mail.gmail.com>
Precedence: bulk

--000000000000c554c906348ab541
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Bogdan,
The root cause here is that the number of huge pages you've configured
(vm.nr_hugepages =3D 980) is not sufficient.
Each huge page on your system is 2=E2=80=AFMB in size, so 980 pages give yo=
u
roughly 1.96=E2=80=AFGB of memory (980 =C3=97 2=E2=80=AFMB). However, Postg=
reSQL is clearly
requesting about 2.2=E2=80=AFGB of shared memory (specifically, 2204106752 =
bytes as
shown in the error message you provided), which exceeds what's available
through huge pages.

That=E2=80=99s why PostgreSQL fails to start when huge_pages =3D on - it re=
quires the
entire shared memory segment to come from huge pages and refuses to fall
back to regular ones.

Earlier, you had the huge_pages setting commented out, which means
PostgreSQL used the default value: huge_pages =3D try. In that mode, it fir=
st
attempts to use huge pages, but if that fails (like in your case due to
insufficient allocation), it falls back to standard memory pages =E2=80=94 =
which is
why the instance started without issues then.

To fix the issue, you should increase vm.nr_hugepages to at least 1100 to
fully cover the shared memory request (you can go a bit higher to be safe
and then reduce it as described in the article I'm pasting the link to).

Also, a side note: max_connections =3D 1000 is quite high for an instance
with 8=E2=80=AFGB of RAM and only 2 vCPUs. Even if huge pages are properly
allocated, such a high number of connections can lead to performance
issues. You might want to consider lowering it or using a connection pooler
like PgBouncer.

If you=E2=80=99d like to understand how huge pages work in PostgreSQL, incl=
uding
how to calculate memory needs and configure the OS properly, I wrote a
detailed article some time ago (still valid). It=E2=80=99s in Polish, which=
 I
assume is fine for you:
https://linuxpolska.com/pl/baza-wiedzy/blog/postgres-pamieci-ram-tipstricks=
/

best regards,
Alicja Kucharczyk

>

--000000000000c554c906348ab541
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Bogdan,</div><div>The root cause here is that the =
number of huge pages you&#39;ve configured (vm.nr_hugepages =3D 980) is not=
 sufficient.<br>Each huge page on your system is 2=E2=80=AFMB in size, so 9=
80 pages give you roughly 1.96=E2=80=AFGB of memory (980 =C3=97 2=E2=80=AFM=
B). However, PostgreSQL is clearly requesting about 2.2=E2=80=AFGB of share=
d memory (specifically, 2204106752 bytes as shown in the error message you =
provided), which exceeds what&#39;s available through huge pages.<br><br>Th=
at=E2=80=99s why PostgreSQL fails to start when huge_pages =3D on - it requ=
ires the entire shared memory segment to come from huge pages and refuses t=
o fall back to regular ones.<br><br>Earlier, you had the huge_pages setting=
 commented out, which means PostgreSQL used the default value: huge_pages =
=3D try. In that mode, it first attempts to use huge pages, but if that fai=
ls (like in your case due to insufficient allocation), it falls back to sta=
ndard memory pages =E2=80=94 which is why the instance started without issu=
es then.<br><br>To fix the issue, you should increase vm.nr_hugepages to at=
 least 1100 to fully cover the shared memory request (you can go a bit high=
er to be safe and then reduce it as described in the article I&#39;m pastin=
g the link to).<br><br>Also, a side note: max_connections =3D 1000 is quite=
 high for an instance with 8=E2=80=AFGB of RAM and only 2 vCPUs. Even if hu=
ge pages are properly allocated, such a high number of connections can lead=
 to performance issues. You might want to consider lowering it or using a c=
onnection pooler like PgBouncer.<br><br>If you=E2=80=99d like to understand=
 how huge pages work in PostgreSQL, including how to calculate memory needs=
 and configure the OS properly, I wrote a detailed article some time ago (s=
till valid). It=E2=80=99s in Polish, which I assume is fine for you: <a hre=
f=3D"https://linuxpolska.com/pl/baza-wiedzy/blog/postgres-pamieci-ram-tipst=
ricks/">https://linuxpolska.com/pl/baza-wiedzy/blog/postgres-pamieci-ram-ti=
pstricks/</a></div><div><br></div><div>best regards,</div><div>Alicja Kucha=
rczyk</div><div class=3D"gmail_quote gmail_quote_container"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>

--000000000000c554c906348ab541--