Re: s_lock() seems too aggressive for machines with many sockets

From: Andres Freund <andres(at)anarazel(dot)de>
To: Nils Goroll <slink(at)schokola(dot)de>
Cc: Jan Wieck <jan(at)wi3ck(dot)info>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: s_lock() seems too aggressive for machines with many sockets
Date: 2015-06-10 15:43:50
Message-ID: 20150610154350.GH10551@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2015-06-10 17:30:33 +0200, Nils Goroll wrote:
> On 10/06/15 17:17, Andres Freund wrote:
> > On 2015-06-10 16:07:50 +0200, Nils Goroll wrote:
> > Interesting. I've been able to reproduce quite massive slowdowns doing
> > this on a 4 socket linux machine (after applying the lwlock patch that's
> > now in 9.5)
>
> Sorry, I cannot comment on this, 9.4.1 is the latest we are running in
> production and I haven't even tested the patch with 9.5.

Ok.

> > As in 200%+ slower.
>
> Have you tried PTHREAD_MUTEX_ADAPTIVE_NP ?

Yes.

> >> Ref: http://www.postgresql.org/message-id/4FEDE0BF.7080203@schokola.de
> >
> > Do you have any details about the workloads that scaled badly back then?
> > It'd be interesting to find out which spinlocks they bottlenecked
> > on.
>
> OLTP. But really the root cause from back then should be eliminated, this was
> with 9.1.3

Hm, ok. Any chance you have profiles from back then? It'd be very
interesting to know which spinlock you were contending on. If we convert
spinlocks into something more heavyweight we'll want to benchmark the
actually contending cases to avoid regressions.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2015-06-10 15:51:06 Re: s_lock() seems too aggressive for machines with many sockets
Previous Message Andres Freund 2015-06-10 15:36:04 Re: replication slot restart_lsn initialization