On Wed, Jul 20, 2011 at 09:46:33PM -0400, Robert Haas wrote: > For the last week or so, in between various other tasks, I've been > trying to understand why performance drops off when you run pgbench -n > -S -c $CLIENTS -j $CLIENTS -T $A_FEW_MINUTES at very high client > counts. The answer, in a word, is SIGetDataEntries(). I believe we > need to bite the bullet and rewrite this using a lock-free algorithm, > using memory barriers on processors with weak memory ordering. > Perhaps there is another way to do it, but nothing I've tried has > really worked so far, and I've tried quite a few things. Here's the > data. > > On unpatched master, performance scales pretty much linearly out to 32 > clients. As you add more clients, it drops off:
> [80 clients] > tps = 132518.586371 (including connections establishing) > tps = 130968.749747 (including connections establishing) > tps = 132574.338942 (including connections establishing) > [80 clients, with lazy vxid locks and sinval-unlocked] > tps = 203256.701227 (including connections establishing) > tps = 190637.957571 (including connections establishing) > tps = 190228.617178 (including connections establishing) Nice numbers. The sinval-unlocked.patch implementation looks like it's taking a sound direction. In http://archives.postgresql.org/message-id/ca+tgmobbxmh_9zjudheswo6m8sbmb5hdzt+3chcluv5eztv...@mail.gmail.com, you quoted 210k TPS when you stubbed out AcceptInvalidationMessages(). Is it correct to conclude that AcceptInvalidationMessages() still reduces the transaction rate by 5-10% with this stack of patches? -- Noah Misch http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, 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
