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

From Nils Goroll
Subject Re: s_lock() seems too aggressive for machines with many sockets
Date
Msg-id 55785819.2040002@schokola.de
Whole thread Raw
In response to Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
Responses Re: s_lock() seems too aggressive for machines with many sockets  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers

On 10/06/15 17:17, Andres Freund wrote:
> On 2015-06-10 16:07:50 +0200, Nils Goroll wrote:
>> On larger Linux machines, we have been running with spin locks replaced by
>> generic posix mutexes for years now. I personally haven't look at the code for
>> ages, but we maintain a patch which pretty much does the same thing still:
> 
> 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.

> As in 200%+ slower.

Have you tried PTHREAD_MUTEX_ADAPTIVE_NP ?

>> 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

I only got woken up by s_lock() in email subjects.

Nils



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: skipping pg_log in basebackup (was Re: pg_basebackup and pg_stat_tmp directory)
Next
From: Andres Freund
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets