Re: Postgres vs. intel ccNUMA on Linux

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: James Robinson <jlrobins(at)socialserve(dot)com>
Cc: Hackers Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Postgres vs. intel ccNUMA on Linux
Date: 2010-09-30 20:49:47
Message-ID: AANLkTinrD+LcK1VZ7w2vO4wFEsYuwt0HT_NvNHoOm00+@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 29, 2010 at 2:45 PM, James Robinson
<jlrobins(at)socialserve(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-09-30 21:02:14 Re: O_DSYNC broken on MacOS X?
Previous Message Kevin Grittner 2010-09-30 20:38:11 Re: git diff --patience