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 по дате отправления: