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

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: s_lock() seems too aggressive for machines with many sockets
Дата
Msg-id 20150610154350.GH10551@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: s_lock() seems too aggressive for machines with many sockets  (Nils Goroll <slink@schokola.de>)
Ответы Re: s_lock() seems too aggressive for machines with many sockets
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: replication slot restart_lsn initialization
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: s_lock() seems too aggressive for machines with many sockets