Re: Scaling PostgreSQL at multicore Power8

From: Dmitry Vasilyev <d(dot)vasilyev(at)postgrespro(dot)ru>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Scaling PostgreSQL at multicore Power8
Date: 2015-08-31 16:14:04
Message-ID: 1441037644.25012.22.camel@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

We did not got any affect on core 64 with smt = 8, and we not have a 64
-cpu x86 machine with disable HT feature.
You can set scale > 1000 and with shared_buffers >> size of index
pgbench_accounts_pkey.
You can also increase the concurrency: not only access top of b-tree
index, but also to a specific buffer: select * from pgbench_accounts
where aid = 1;

On Mon, 2015-08-31 at 17:43 +0200, Tomas Vondra wrote:
>
> On 08/31/2015 12:54 PM, YUriy Zhuravlev wrote:
> > Hello hackers
> >
> > Recently, we were given access to the test server is IBM, 9119-MHE
> > with 8 CPUs
> > * 8 cores * 8 threads. We decided to take advantage of this and to
> > find
> > bottlenecks for read scalability (pgbench -S).
> >
> > All detail you can read here:
> > http://www.postgrespro.ru/blog/pgsql/2015/08/30/p8scaling
> >
> > Performance 9.4 stopped growing after 100 clients, and 9.5 / 9.6
> > stopped after
> > 150 (at 4 NUMA nodes). After research using pref we saw that
> > inhibits
> > ProcArrayLock in GetSnaphotData. But inserting the stub instead of
> > GetSnapshotData not significantly increased scalability. Trying to
> > find the
> > bottleneck with gdb, we found another place. We have noticed s_lock
> > in
> > PinBuffer and UnpinBuffer. For the test we rewrited PinBuffer and
> > UnpinBuffer
> > by atomic operations and we liked the result. Degradation of
> > performance
> > almost completely disappeared, and went scaling up to 400 clients
> > (4 NUMA
> > nodes with 256 "CPUs").
> >
> > To scale Postgres for large NUMA machine must be ported to the
> > atomic
> > operations bufmgr. During our tests, we no found errors in our
> > patch, but most
> > likely it is not true and this patch only for test.
> >
> > Who has any thoughts?
>
> Well, I could test the patch on a x86 machine with 4 sockets (64
> cores),
> but I wonder whether it makes sense at this point, as the patch
> really
> is not correct (judging by what Andres says).
>
> Also, what pgbench scale was used for the testing?
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2015-08-31 16:24:49 Re: Missing latex-longtable value
Previous Message YUriy Zhuravlev 2015-08-31 16:13:40 Re: Scaling PostgreSQL at multicore Power8