Re: Kevin Grittner 2014-07-01 <1404213492.98740.YahooMailNeo@web122306.mail.ne1.yahoo.com>
> Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2014-07-01 11:01:04 +0200, Christoph Berg wrote:
>
> >> How much difference would it make if numactl --interleave=all
> >> was used instead of using numa_interleave_memory() on the shared
> >> memory segments? I guess that would make backend-local memory
> >> also interleaved, but it would avoid having a dependency on
> >> libnuma in the packages.
> >
> > I've tested this a while ago, and it's rather painful if you have
> > a OLAP workload with lots of backend private memory.
>
> I'm not surprised; I would expect it to generally have a negative
> effect, which would be most pronounced with an OLAP workload.
Ok, then +1 on having this in core, even if it buys us a dependency on
something that isn't in the usual base system after OS install.
> > I wonder if we shouldn't backpatch such a notice.
>
> I would want to see some evidence that it was useful first. In
> most of my tests the benefit of interleaving just the OS cache and
> PostgreSQL shared_buffers was about 2%. That could easily be
> erased if work_mem allocations and other process-local memory were
> not allocated close to the process which was using it.
>
> I expect that the main benefit of this proposed patch isn't the 2%
> typical benefit I was seeing, but that it will be insurance against
> occasional, much larger hits. I haven't had much luck making these
> worst case episodes reproducible, though.
Afaict, the numactl notice will only be useful as a postscriptum to
the --with-libnuma docs, with the caveats mentioned. Or we backpatch
(something like) the full docs of the feature, with a note that it's
only 9.5+. (Or the full feature gets backpatched...)
Christoph
--
cb@df7cb.de | http://www.df7cb.de/