Re: Postgres vs. intel ccNUMA on Linux - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Postgres vs. intel ccNUMA on Linux
Date
Msg-id AANLkTinrD+LcK1VZ7w2vO4wFEsYuwt0HT_NvNHoOm00+@mail.gmail.com
Whole thread Raw
In response to Postgres vs. intel ccNUMA on Linux  (James Robinson <jlrobins@socialserve.com>)
List pgsql-hackers
On Wed, Sep 29, 2010 at 2:45 PM, James Robinson
<jlrobins@socialserve.com> wrote:
> Hackers,
>
>        Any tips / conventional wisdom regarding running postgres on
> large-ish memory ccNUMA intel machines, such as a 32G dual-quad-core,
> showing two NUMA nodes of 16G each? I expect each postgres backend's
> non-shared memory usage to remain nice and reasonably sized, hopefully
> staying within the confines of its processor's local memory region, but how
> will accesses to shared memory and / or buffer cache play out? Do people
> tune their backends via 'numactl' ?
>
>        Furthermore, if one had more than one database being served by the
> machine, would it be advisable to do this via multiple clusters instead of a
> single cluster, tweaking the processor affinity of each postmaster
> accordingly, trying to ensure each cluster's shared memory segments and
> buffer cache pools remain local for the resulting backends?

I was hoping someone more knowledgeable about this topic would reply, but...

Generally, I don't recommend running more than one postmaster on one
machine, because one big pool for shared_buffers is generally going to
be more efficient than two smaller pools.  However, as you say, the
shared memory region might be a problem, particularly for things like
the ProcArray, which are pretty "hot" and are accessed by every
backend during every transaction.  But I'm not sure whether the
additional overhead is going to be more or less than the overhead of
splitting the shared_buffers arena in half, so I suspect you're going
to have to benchmark it to find out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: git diff --patience
Next
From: Tom Lane
Date:
Subject: Re: O_DSYNC broken on MacOS X?