| From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Wait free LW_SHARED acquisition |
| Date: | 2013-09-27 07:14:46 |
| Message-ID: | 52453066.9090102@vmware.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-09-27 07:21:05 | Re: Wait free LW_SHARED acquisition |
| Previous Message | Daniel Farina | 2013-09-27 07:07:31 | Re: Some interesting news about Linux 3.12 OOM |