Re: s_lock() seems too aggressive for machines with many sockets - Mailing list pgsql-hackers

From Andres Freund
Subject Re: s_lock() seems too aggressive for machines with many sockets
Date
Msg-id 20150610154350.GH10551@awork2.anarazel.de
Whole thread Raw
In response to Re: s_lock() seems too aggressive for machines with many sockets  (Nils Goroll <slink@schokola.de>)
Responses Re: s_lock() seems too aggressive for machines with many sockets
List 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.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: replication slot restart_lsn initialization
Next
From: Jan Wieck
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets