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 > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers