On Thu, May 24, 2012 at 2:19 PM, Sergey Koposov <kopo...@ast.cam.ac.uk> wrote: > On Thu, 24 May 2012, Robert Haas wrote: >> On Thu, May 24, 2012 at 1:42 PM, Sergey Koposov <kopo...@ast.cam.ac.uk> >> wrote: >>> >>> I guess there is nothing catastrophically wrong with that, but still I'm >>> very suprised that you get severe locking problems (factor of two >>> slow-down) >>> when running parallel read-only transactions. >> >> Me, too. How many concurrent connections are you running, and does >> your working set exceed shared_buffers? Can you provide a >> self-contained reproducible test case? > > The last tests I've been doing were with 8 connections. > And the working set is roughly 30Gig, which is ~ 3x the shared buffers. (but > ~ 50% of RAM).
Given that additional information, I would say these results are expected. Unfortunately, our BufFreelistLock is a serious contention point, and I think that's what you're hitting. See the graph here: http://rhaas.blogspot.com/2012/03/performance-and-scalability-on-ibm.html As you can see, raw performance isn't much worse with the larger data sets, but scalability at high connection counts is severely degraded once the working set no longer fits in shared_buffers. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
