public inbox for [email protected]
help / color / mirror / Atom feedRe: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory
3+ messages / 3 participants
[nested] [flat]
* Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory
@ 2025-05-07 12:16 Alicja Kucharczyk <[email protected]>
2025-05-07 16:36 ` Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory Bogdan Siara <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Alicja Kucharczyk @ 2025-05-07 12:16 UTC (permalink / raw)
To: Bogdan Siara <[email protected]>; +Cc: [email protected]
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
>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory
2025-05-07 12:16 Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory Alicja Kucharczyk <[email protected]>
@ 2025-05-07 16:36 ` Bogdan Siara <[email protected]>
2025-05-07 16:52 ` Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory Greg Sabino Mullane <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Bogdan Siara @ 2025-05-07 16:36 UTC (permalink / raw)
To: Alicja Kucharczyk <[email protected]>; +Cc: [email protected]
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
>
>>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory
2025-05-07 12:16 Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory Alicja Kucharczyk <[email protected]>
2025-05-07 16:36 ` Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory Bogdan Siara <[email protected]>
@ 2025-05-07 16:52 ` Greg Sabino Mullane <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Greg Sabino Mullane @ 2025-05-07 16:52 UTC (permalink / raw)
To: Bogdan Siara <[email protected]>; +Cc: Alicja Kucharczyk <[email protected]>; [email protected]
Kudos to Alicja for that excellent answer.
It would be nice if the Postgres log message was a little more descriptive.
(throws it onto my huge pile of "future maybe enhancement ideas")
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2025-05-07 16:52 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-05-07 12:16 Re: huge_pages=on cause could not map anonymous shared memory: Cannot allocate memory Alicja Kucharczyk <[email protected]>
2025-05-07 16:36 ` Bogdan Siara <[email protected]>
2025-05-07 16:52 ` Greg Sabino Mullane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox