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.
>> 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
