Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Bogdan Siara <[email protected]>
To: Alicja Kucharczyk <[email protected]>
Cc: [email protected]
Subject: Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory
Date: Wed, 7 May 2025 18:36:20 +0200
Message-ID: <CAJCjmttdbh6TPYqr+4X5tr+m2m=-QgHq+xe92AOxnXaxMRS6RQ@mail.gmail.com> (raw)
In-Reply-To: <CAM=sWa5eM2_M_jqdYnU45nOuB_R=V8i8koS_hX0cAFjjSChv+w@mail.gmail.com>
References: <CAJCjmtsEtKMyBxZDg3Do72fr+VVF0eVUdt1aBUctD9BVEt_LNg@mail.gmail.com>
	<CAM=sWa5eM2_M_jqdYnU45nOuB_R=V8i8koS_hX0cAFjjSChv+w@mail.gmail.com>

Hi Alicja,
Thanks for your advice, now postgresql works fine with 'huge_pages=on'.
Regards
Bogdan

śr., 7 maj 2025 o 14:17 Alicja Kucharczyk <[email protected]>
napisał(a):

> Hi Bogdan,
> The root cause here is that the number of huge pages you've configured
> (vm.nr_hugepages = 980) is not sufficient.
> Each huge page on your system is 2 MB in size, so 980 pages give you
> roughly 1.96 GB of memory (980 × 2 MB). However, PostgreSQL is clearly
> requesting about 2.2 GB of shared memory (specifically, 2204106752 bytes as
> shown in the error message you provided), which exceeds what's available
> through huge pages.
>
> That’s why PostgreSQL fails to start when huge_pages = on - it requires
> 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 = try. In that mode, it first
> attempts to use huge pages, but if that fails (like in your case due to
> insufficient allocation), it falls back to standard memory pages — 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 = 1000 is quite high for an instance
> with 8 GB 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’d 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 (still valid). It’s in Polish, which I
> assume is fine for you:
> https://linuxpolska.com/pl/baza-wiedzy/blog/postgres-pamieci-ram-tipstricks/
>
> best regards,
> Alicja Kucharczyk
>
>>

view thread (3+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory
  In-Reply-To: <CAJCjmttdbh6TPYqr+4X5tr+m2m=-QgHq+xe92AOxnXaxMRS6RQ@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox