Re: NUMA packaging and patch

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.

>> The numactl manpage even has this example:
>>
>>     numactl --interleave=all bigdatabase arguments Run big
>>     database with its memory interleaved on all CPUs.
>>
>> It is probably better to have native support in the postmaster,
>> though this could be mentioned as an alternative in the
>> documentation.
>
> 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.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company