From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>, Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: 60 core performance with 9.3 |
Date: | 2014-07-21 14:19:13 |
Message-ID: | 1405952353.75554.YahooMailNeo@web122302.mail.ne1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | johno | 2014-07-21 21:09:19 | Slow query with indexed ORDER BY and LIMIT when using OR'd conditions |
Previous Message | Albe Laurenz | 2014-07-21 08:02:37 | Re: Blocking every 20 sec while mass copying. |