On Mon, Oct 22, 2012 at 3:24 PM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> 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. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
