On Mon, Oct 22, 2012 at 3:24 PM, Shaun Thomas <sthomas@optionshouse.com> wrote:
>> http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-archite
>> cture/
>
>
> Yeah, I remember reading that a while back. While interesting, it doesn't
> really apply to PG, in that unlike MySQL, we don't allocate any large memory
> segments directly to any large block. With MySQL, it's not uncommon to
> dedicate over 50% of RAM to the MySQL process itself, but I don't often see
> PG systems with more than 8GB in shared_buffers.
Actually, one problem that creeps up in PG is that shared buffers
tends to be allocated all within one node (the postmaster's), stealing
a lot from workers.
I had written a patch that sets the policy to interleave in the
master, while launching (and setting up shared buffers), and then back
to preferring local when forking a worker.
I never had a chance to test it. I only have one numa system, and it's
in production so I can't really test much there.
I think, unless it gives you trouble with the page cache, numactl
--prefer=+0 should work nicely for postgres overall. Failing that,
numactl --interleave=all would, IMO, be better than the system
default.