Re: Tons of free RAM. Can't make it go away.

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.

In response to

Responses

Browse pgsql-performance by date

  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.