Re: NUMA packaging and patch

Re: Kevin Grittner 2014-07-01 <1404213492(dot)98740(dot)YahooMailNeo(at)web122306(dot)mail(dot)ne1(dot)yahoo(dot)com>
> Andres Freund <andres(at)2ndquadrant(dot)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(at)df7cb(dot)de | http://www.df7cb.de/