Re: [PATCH] Use MAP_HUGETLB where supported (v3)

From: Sergey Konoplev <gray(dot)ru(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)2ndquadrant(dot)com>, hlinnakangas(at)vmware(dot)com
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Date: 2013-10-30 21:28:43
Message-ID: CAL_0b1ucFq4DpGYHXczW2MU+NSpr0d4M3ry=G_uNUb-x5VqSQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 30, 2013 at 12:51 PM, Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> wrote:
> On Wed, Oct 30, 2013 at 12:17 PM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>>> > I wasn't talking about a built-in support. It was about an ability (a
>>> > way) to back sh_buf with hugepages.
>>>
>>> Then what you need is to set
>>> dynamic_shared_memory_type = sysv
>>> in postgresql.conf.
>>
>> The above is mistaken -- there's no way to disable the mmap() segment in
>> 9.3, other than recompiling with EXEC_BACKEND which is probably
>> undesirable for other reasons.
>
> Alternatively, I assume it could be linked with libhugetlbfs and you
> don't need any source modifications in this case. However I am not
> sure it will work with shared memory.

BTW, I managed to run 9.3 backed with hugepages after I put
HUGETLB_MORECORE (see man libhugetlbfs) to the environment yesterday,
but, after some time of working, it failed with messages showed below.

syslog:

Oct 29 17:53:13 grayhemp kernel: [150579.903875] PID 7584 killed due
to inadequate hugepage pool

postgres:

libhugetlbfslibhugetlbfs2013-10-29 17:53:21 PDT LOG: server process
(PID 7584) was terminated by signal 7: Bus error
2013-10-29 17:53:21 PDT LOG: terminating any other active server processes
2013-10-29 1
7:53:21 PDT WARNING: terminating connection because of crash of
another server process
2013-10-29 17:53:21 PDT DETAIL: The postmaster has commanded this
server process to roll back the current transaction and exit, because
another server process exited abnormally and possibly corrupted shared
memory.

My theory is that it has happened after the amount of huge pages
(vm.nr_overcommit_hugepages + vm.nr_hugepages) was exceeded, but I
might be wrong.

Does anybody has some thoughts of why it has happened and how to work abound it?

--
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray(dot)ru(at)gmail(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-10-30 21:32:46 Re: How can I build OSSP UUID support on Windows to avoid duplicate UUIDs?
Previous Message Gurjeet Singh 2013-10-30 21:11:08 Shave a few instructions from child-process startup sequence