From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | sthomas(at)optionshouse(dot)com |
Cc: | "Franklin, Dan (FEN)" <Dan(dot)Franklin(at)pearson(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Tons of free RAM. Can't make it go away. |
Date: | 2012-10-22 18:44:50 |
Message-ID: | CAGTBQpY+qNJ7N9tcPTe-OQqtAwmSD6ov+DETXJ8-fB4nfHv6VQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Oct 22, 2012 at 3:24 PM, Shaun Thomas <sthomas(at)optionshouse(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Burbridge | 2012-10-23 15:42:10 | Prepared statements slow in 9.2 still (bad query plan) |
Previous Message | Shaun Thomas | 2012-10-22 18:28:19 | Re: Tons of free RAM. Can't make it go away. |