pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Kevin Grittner <kgrittn@ymail.com>
To: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: 60 core performance with 9.3
Date: Mon, 21 Jul 2014 07:19:13 -0700
Message-ID: <1405952353.75554.YahooMailNeo@web122302.mail.ne1.yahoo.com> (raw)
In-Reply-To: <53C71429.3000107@catalyst.net.nz>
References: <53ACB190.2030206@catalyst.net.nz>
	<CAOR=d=3=Y6yNtwQenwVBGe6ZgjAeA8PwgYb3=aQEKn+vYWhBJA@mail.gmail.com>
	<53ACD6C4.9050605@catalyst.net.nz>
	<20140627091951.GA16680@awork2.anarazel.de>
	<53B283F3.7020005@catalyst.net.nz>
	<20140701101307.GO21422@awork2.anarazel.de>
	<53BF326F.2070903@catalyst.net.nz>
	<20140711082207.GI17261@awork2.anarazel.de>
	<53BFA63C.60909@catalyst.net.nz>
	<1405084749.26978.YahooMailNeo@web122306.mail.ne1.yahoo.com>
	<53C71429.3000107@catalyst.net.nz>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

Mark Kirkwood <mark.kirkwood@catalyst.net.nz> wrote:
> On 12/07/14 01:19, Kevin Grittner wrote:
>>
>> It might be worth a test using a cpuset to interleave OS cache and
>> the NUMA patch I submitted to the current CF to see whether this is
>> getting into territory where the patch makes a bigger difference.
>> I would expect it to do much better than using numactl --interleave
>> because work_mem and other process-local memory would be allocated
>> in "near" memory for each process.
>>
> http://www.postgresql.org/message-id/1402267501.41111.YahooMailNeo@web122304.mail.ne1.yahoo.com
>
> Thanks Kevin - I did try this out - seemed slightly better than using
> --interleave, but almost identical to the results posted previously.
>
> However looking at my postgres binary with ldd, I'm not seeing any link
> to libnuma (despite it demanding the library whilst building), so I
> wonder if my package build has somehow vanilla-ified the result :-(

That is odd; not sure what to make of that!

> Also I am guessing that with 60 cores I do:
>
> $ sudo /bin/bash -c "echo 0-59 >/dev/cpuset/postgres/cpus"
>
> i.e cpus are cores not packages...?

Right; basically, as a guide, you can use the output from:

$ numactl --hardware

Use the union of all the "cpu" numbers from the "node n cpus" lines.  The
above statement is also a good way to see how unbalance memory usage has
become while running a test.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance



view thread (26+ messages)  latest in thread

Message-ID: <1405952353.75554.YahooMailNeo@web122302.mail.ne1.yahoo.com>
Permalink:  ../1405952353.75554.YahooMailNeo@web122302.mail.ne1.yahoo.com/
Also on:    postgresql.org/message-id/1405952353.75554.YahooMailNeo@web122302.mail.ne1.yahoo.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: kgrittn@ymail.com, mark.kirkwood@catalyst.net.nz, andres@2ndquadrant.com
  Subject: Re: 60 core performance with 9.3
  In-Reply-To: <1405952353.75554.YahooMailNeo@web122302.mail.ne1.yahoo.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox