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

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 Suppor

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

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 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 p

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

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

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

Hi, I have problem to run postgresql on ubuntu 24.04 server with huge_pages = on. My instance have 8GB ram and 2 vcpus (t3a.large). My configuration is: max_connections = 1000 superuser_reserved_connections = 3 shared_buffers = 1960MB effective_cache_size = 5881MB huge_pages = on temp_buffers = 32