On 27.09.2013 01:55, Andres Freund wrote:
> Hello,
>
> 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?
- Heikki
