Re: Huge pages section needs to describe hugetlb_shm_group, memlock limit

Regarding the coverage of huge pages (added in 9.4):
http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-HUGE-PAGES

This section does not call out the need to add the PostgreSQL user to a
group which has been given access to shared memory by setting its number as
vm.hugetlb_shm_group, nor that the "memlock" limit needs to be raised or set
to unlimited for this user.

If these are not done, postgres would need to be running as a user with
CAP_IPC_LOCK (e.g. root) to take advantage of large pages. These
restrictions exist because reserving a large page locks it in physical
memory, which can lead to resource exhaustion.

Compare http://dev.mysql.com/doc/refman/5.7/en/large-page-support.html which
mentions both of these issues (although it does not show adding the user to
the group, just setting the group as vm.hugetlb_shm_group).

An example command sequence:
groupadd hugepages
gpasswd -a postgres hugepages
id postgres [user finds "hugepages" group has id 1234]

sysctl -w vm.hugetlb_shm_group=1234
sysctl -w vm.nr_hugepages=5678 [as estimated in documentation]

Edit /etc/sysctl.conf and add:
vm.hugetlb_shm_group=1234
vm.nr_hugepages=5678

Add to /etc/security/limits.conf:
@hugepages soft memlock unlimited
@hugepages hard memlock unlimited

In some cases (e.g. Debian's start-stop-daemon) the command "ulimit -l
unlimited" may be needed in the PostgreSQL startup scripts instead of the
limits.conf edit, because PAM limits are not called for those scripts.

Hope this helps,
--
Laurence "GreenReaper" Parry
http://greenreaper.co.uk - http://wikifur.com - http://flayrah.com
"Eternity lies ahead of us, and behind. Have you drunk your fill?"

On Sat, Sep 20, 2014 at 10:24:51PM +0100, Laurence Parry wrote:
> Regarding the coverage of huge pages (added in 9.4):
> http://www.postgresql.org/docs/9.4/static/kernel-resources.html#LINUX-HUGE-PAGES
>
> This section does not call out the need to add the PostgreSQL user
> to a group which has been given access to shared memory by setting
> its number as vm.hugetlb_shm_group, nor that the "memlock" limit
> needs to be raised or set to unlimited for this user.
>
> If these are not done, postgres would need to be running as a user
> with CAP_IPC_LOCK (e.g. root) to take advantage of large pages.
> These restrictions exist because reserving a large page locks it in
> physical memory, which can lead to resource exhaustion.
>
> Compare
> http://dev.mysql.com/doc/refman/5.7/en/large-page-support.html which
> mentions both of these issues (although it does not show adding the
> user to the group, just setting the group as vm.hugetlb_shm_group).
>
> An example command sequence:
> groupadd hugepages
> gpasswd -a postgres hugepages
> id postgres [user finds "hugepages" group has id 1234]
>
> sysctl -w vm.hugetlb_shm_group=1234
> sysctl -w vm.nr_hugepages=5678 [as estimated in documentation]
>
> Edit /etc/sysctl.conf and add:
> vm.hugetlb_shm_group=1234
> vm.nr_hugepages=5678
>
> Add to /etc/security/limits.conf:
> @hugepages soft memlock unlimited
> @hugepages hard memlock unlimited
>
> In some cases (e.g. Debian's start-stop-daemon) the command "ulimit
> -l unlimited" may be needed in the PostgreSQL startup scripts
> instead of the limits.conf edit, because PAM limits are not called
> for those scripts.

I have applied the attached doc patch.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +