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