On 01/13/2014 05:30 PM, Dave Chinner wrote:
> On Mon, Jan 13, 2014 at 03:24:38PM -0800, Josh Berkus wrote:
> No matter what default NUMA allocation policy we set, there will be
> an application for which that behaviour is wrong. As such, we've had
> tools for setting application specific NUMA policies for quite a few
> years now. e.g:
Yeah, that's why I personally regard the NUMA stuff as just an
information problem; there's an easy configuration variable, and you
can't please everyone (and our project would hardly be one to point
fingers about sub-optimal default configurations). I was responding to
a question of "what's wrong with the default setting?"
Personally, I have my doubts that the NUMA memory isolation, as
currently implemented, accomplishes what it wants to do. But that's a
completely different discussion.
The real issue there was that our users had never heard of this change
until suddenly half their RAM became unavailable. So the solution is
for our project to somehow have these kinds of changes flagged for our
attention so that we can update our docs. The kernel change list is
quite volumnious, and it's very easy to miss changes of significance in
it. The easiest way to do this is going to be getting involved in
kernel-database performance testing.
Of course, we are annoyed that we finally removed the main reason to
modify sysctl.conf (SHMMAX), and here we are needing to advise users
about sysctl again. :-(
I'm much more bothered by the introduction of 2Q logic, since that comes
without a configuration variable to modify its behavior.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com