From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Scalia <jayknowsunix@gmail.com>
Cc: pgsql-admin@postgresql.org <pgsql-admin@postgresql.org>
Subject: Re: hugepage configuration for V.9.4.0
Date: Thu, 29 Jan 2015 13:18:16 -0500
Message-ID: <11110.1422555496@sss.pgh.pa.us> (raw)
In-Reply-To: <54CA73CE.1050503@gmail.com>
References: <54CA73CE.1050503@gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-admin>
John Scalia <jayknowsunix@gmail.com> writes:
> 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 continue to 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.
FWIW, I think that the transparent_hugepage setting is irrelevant to this.
The whole point here is that we're explicitly asking for a hugepage memory
segment, so the OS doesn't have to try to make it transparent.
What might be happening is that when requesting a hugepage segment, we
actually round up the request (here claimed to be 1124876288 bytes)
to the next 2MB boundary. Is it possible your kernel settings are
such that the slightly larger request fails?
Also, there may well be request limits that apply specifically to hugepage
segments; I don't know too much about that.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
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: pgsql-admin@postgresql.org
Cc: tgl@sss.pgh.pa.us, jayknowsunix@gmail.com
Subject: Re: hugepage configuration for V.9.4.0
In-Reply-To: <11110.1422555496@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox