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