Hi,
On 2013-09-27 10:14:46 +0300, Heikki Linnakangas wrote:
> On 27.09.2013 01:55, Andres Freund wrote:
> >We have had several customers running postgres on bigger machines report
> >problems on busy systems. Most recently one where a fully cached
> >workload completely stalled in s_lock()s due to the *shared* lwlock
> >acquisition in BufferAlloc() around the buffer partition lock.
> >
> >Increasing the padding to a full cacheline helps making the partitioning
> >of the partition space actually effective (before it's essentially
> >halved on a read-mostly workload), but that still leaves one with very
> >hot spinlocks.
> >
> >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.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services