Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
