Re: Shared Memory: How to use SYSV rather than MMAP ?

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "REIX, Tony" <tony(dot)reix(at)atos(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, "EMPEREUR-MOT, SYLVIE" <sylvie(dot)empereur-mot(at)atos(dot)net>
Subject: Re: Shared Memory: How to use SYSV rather than MMAP ?
Date: 2018-12-26 19:59:01
Message-ID: CAEepm=3qfU0x2tDPp_KfJFkBZLXTazmWGRVqsWzamr1LS3MzQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Dec 27, 2018 at 6:48 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Dec 26, 2018 at 11:43 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> > > Since it's not fixing a bug, we wouldn't back-patch that into existing
> > > releases. But I agree that we should do something like this for
> > > PostgreSQL 12, and I think we should make it user configurable.
> >
> > I'm -1 on making this user configurable via a GUC; that adds documentation
> > and compatibility burdens that we don't need, for something of no value
> > to 99.99% of users. The fact that the default would need to be
> > platform-dependent just makes that tradeoff even worse. I think the other
> > 0.01% who need to change the default (and are bright enough to be doing
> > the right thing for the right reasons) could certainly handle something
> > like a pg_config_manual.h control symbol --- see USE_PPC_LWARX_MUTEX_HINT
> > for a precedent that I think applies well here. So I'd favor just doing
> > it that way.
>
> I disagree. I think there is a growing body of evidence that
> b0fc0df9364d2d2d17c0162cf3b8b59f6cb09f67 killed performance on many
> types of non-Linux systems. This is the first report I recall about
> AIX, but there have been previous complaints about some BSD variants.

FTR, I think the main FreeBSD complaint in a nutshell was:

1. There are/were some lock contention problems on internal VM
objects and page tracking structures (pv entries copied for every
process sharing a VM object).
2. SysV shmem offers a workaround in the form of sysctl
kern.ipc.shm_use_phys which effectively pins all SysV shared memory
(so it shows up in procstat -v as "ph" rather than "sw", ie it's not
swappable). "Unmanaged pages never require finding all the instances
of their mappings, so the associated data structure used to find all
mappings (Described in Section 6.13) need not be allocated" (from 6.10
in the D&I of FreeBSD book).
3. Shared anonymous mmap has no way to ask for that.

That wasn't all, though; see the PDF I mentioned up-thread. I'm
hoping to learn more about this subject, hence my interest in reviving
that patch. So far I can't reproduce the effect here, probably due to
lack of cores and probably also various changes that have been made
(but not the main ones described in that report, apparently).

--
Thomas Munro
http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-12-26 20:19:15 Re: random() (was Re: New GUC to sample log queries)
Previous Message Peter Geoghegan 2018-12-26 19:56:04 Re: random() (was Re: New GUC to sample log queries)