From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Wait free LW_SHARED acquisition |
Date: | 2013-09-27 08:18:07 |
Message-ID: | 20130927081807.GC5588@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-09-27 09:57:07 +0200, Andres Freund wrote:
> On 2013-09-27 09:21:05 +0200, Andres Freund wrote:
> > > >So the goal is to have LWLockAcquire(LW_SHARED) never block unless
> > > >somebody else holds an exclusive lock. To produce enough appetite for
> > > >reading the rest of the long mail, here's some numbers on a
> > > >pgbench -j 90 -c 90 -T 60 -S (-i -s 10) on a 4xE5-4620
> > > >
> > > >master + padding: tps = 146904.451764
> > > >master + padding + lwlock: tps = 590445.927065
> > >
> > > How does that compare with simply increasing NUM_BUFFER_PARTITIONS?
> >
> > Heaps better. In the case causing this investigation lots of the pages
> > with hot spinlocks were the simply the same ones over and over again,
> > partitioning the lockspace won't help much there.
> > That's not exactly an uncommon scenario since often enough there's a
> > small amount of data hit very frequently and lots more that is accessed
> > only infrequently. E.g. recently inserted data and such tends to be very hot.
> >
> > I can run a test on the 4 socket machine if it's unused, but on my 2
> > socket workstation the benefits of at least our simulation of the
> > original workloads the improvements were marginal after increasing the
> > padding to a full cacheline.
>
> Ok, was free:
>
> padding + 16 partitions:
> tps = 147884.648416
>
> padding + 32 partitions:
> tps = 141777.841125
>
> padding + 64 partitions:
> tps = 141561.539790
>
> padding + 16 partitions + new lwlocks
> tps = 601895.580903 (yeha, still reproduces after some sleep!)
Pgbench numbers for writes on the machine (fsync = off,
synchronous_commit = off):
padding + 16 partitions:
tps = 8903.532163
vs
padding + 16 partitions + new lwlocks
tps = 13324.080491
So, on bigger machines the advantages seem to be there for writes as
well...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Pavan Deolasee | 2013-09-27 08:18:57 | Re: Patch for fail-back without fresh backup |
Previous Message | Heikki Linnakangas | 2013-09-27 08:11:56 | Re: Wait free LW_SHARED acquisition |