hugepage configuration for V.9.4.0 - Mailing list pgsql-admin

From John Scalia
Subject hugepage configuration for V.9.4.0
Date
Msg-id 54CA73CE.1050503@gmail.com
Whole thread Raw
Responses Re: hugepage configuration for V.9.4.0  (Michael Heaney <mheaney@jcvi.org>)
Re: hugepage configuration for V.9.4.0  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
I'm certain that I'm no expert for this one, as I've never had to configure this parameter for anything prior, but I
continueto get a startup error when I try to use this. The  
server is a VM running CentOS 6.5 with 4 Gb allocated to it. When I started setting "huge_pages = on", the server
reported:

%FATAL: could not map anonymous shared memory: Cannot allocate memory
%HINT: this error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap
space,or huge pages. To reduce the request size (currently  
1124876288 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

Further research showed that server's /sys/kernel/mm/transparent_hugepage/enabled file contained "[always] madvise
never"

As I was concerned about the "always" setting, I used "cat madvise > " to the file so it reported "always [madvise]
never"I even set this in /etc/rc.local and performed a reboot. 

Regardless of which setting, however, I receive the same failure message. Per its suggestions, my settings are
shared_buffers= 1024Mb and max_connections = 100. 

Should I reduce these values? Is a 4 Gb test server too small to use huge_pages? The server does run just fine with
"huge_pages= try" or "off". What else should I be checking? 
--
Jay




pgsql-admin by date:

Previous
From: David Susa
Date:
Subject: Postgresql partitioning limit - possible bottlenecks
Next
From: Scott Whitney
Date:
Subject: Re: hugepage configuration for V.9.4.0