Re: Doc tweak for huge_pages?

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Adrien Nayrat <adrien(dot)nayrat(at)dalibo(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Doc tweak for huge_pages?
Date: 2017-12-04 13:09:26
Message-ID: 20171204130926.GF14008@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Dec 04, 2017 at 09:48:44AM +0100, Adrien Nayrat wrote:
> On 12/01/2017 05:35 AM, Thomas Munro wrote:
> >> since it also supports "transparent" hugepages.
> > Hmm. Yeah, it does, but apparently it's not so transparent.
>
> +1. We saw performance drop with transparent_hugepage enabled on server with
> more than 256GB RAM. Access to the cache where slow down when kernel try to
> defragment pages.
> consuming function with perf top.
>
> Thanks to Marc Cousin analysis, putting "madvise" to
> /sys/kernel/mm/transparent_hugepage/enabled solved the problem. He also notice
> that THP only works for "anonymous memory mappings"[1] (shared_buffers are not
> anonymous).

Note PG since 9.3 can and prefers to use anonymous mmap for shared buffers instead
of sysv shm.

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b0fc0df9364d2d2d17c0162cf3b8b59f6cb09f67
./src/backend/port/sysv_shmem.c and
src/include/portability/mem.h:#define PG_MMAP_FLAGS (MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE)

Justin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Lyes Ameddah 2017-12-04 13:59:33 Re: BUG #14941: Vacuum crashes
Previous Message Jakub Glapa 2017-12-04 12:18:38 Re: ERROR: too many dynamic shared memory segments