pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Andres Freund <andres@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: 60 core performance with 9.3
Date: Fri, 11 Jul 2014 20:54:20 +1200
Message-ID: <53BFA63C.60909@catalyst.net.nz> (raw)
In-Reply-To: <20140711082207.GI17261@awork2.anarazel.de>
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>
List-Unsubscribe:  <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>

On 11/07/14 20:22, Andres Freund wrote:
> On 2014-07-11 12:40:15 +1200, Mark Kirkwood wrote:

>> Postgres 9.4 beta
>> rwlock patch
>> pgbench scale = 2000
>>
> On that scale - that's bigger than shared_buffers IIRC - I'd not expect
> the patch to make much of a difference.
>

Right - we did test with it bigger (can't recall exactly how big), but 
will retry again after setting the numa parameters below.

>> #
>>       8.82%        postgres  [kernel.kallsyms]        [k]
>> _raw_spin_lock_irqsave
>>                    |
>>                    --- _raw_spin_lock_irqsave
>>                       |
>>                       |--75.69%-- pagevec_lru_move_fn
>>                       |          __lru_cache_add
>>                       |          lru_cache_add
>>                       |          putback_lru_page
>>                       |          migrate_pages
>>                       |          migrate_misplaced_page
>>                       |          do_numa_page
>>                       |          handle_mm_fault
>>                       |          __do_page_fault
>>                       |          do_page_fault
>>                       |          page_fault
>
> So, the majority of the time is spent in numa page migration. Can you
> disable numa_balancing? I'm not sure if your kernel version does that at
> runtime or whether you need to reboot.
> The kernel.numa_balancing sysctl might work. Otherwise you probably need
> to boot with numa_balancing=0.
>
> It'd also be worthwhile to test this with numactl --interleave.
>

That was my feeling too - but I had no idea what the magic switch was to 
tame it (appears to be in 3.13 kernels), will experiment and report 
back. Thanks again!

Mark



-- 
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: <53BFA63C.60909@catalyst.net.nz>
Permalink:  ../53BFA63C.60909@catalyst.net.nz/
Also on:    postgresql.org/message-id/53BFA63C.60909@catalyst.net.nz

 · 

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: mark.kirkwood@catalyst.net.nz, andres@2ndquadrant.com
  Subject: Re: 60 core performance with 9.3
  In-Reply-To: <53BFA63C.60909@catalyst.net.nz>

* 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