Skip site navigation (1) Skip section navigation (2)

Re: sinval synchronization considered harmful

From: Noah Misch <noah(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: sinval synchronization considered harmful
Date: 2011-07-21 20:54:31
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.

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          
PostgreSQL Development, 24x7 Support, Training & Services

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2011-07-21 21:13:18
Subject: Re: pg_upgrade and log file output on Windows
Previous:From: Pavan DeolaseeDate: 2011-07-21 20:19:26
Subject: Re: Single pass vacuum - take 1

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group