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 20150610151715.GE10551@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  (Nils Goroll <slink@schokola.de>)
Список pgsql-hackers
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) in readonly workloads. As in 200%+ slower. And that was with
a new kernel/glibc.  That was primarily due to buffer header
spinlocks. For write workloads the difference was smaller, but still
noticeably. There xlog.c's spinlocks where noticeable which are usually
held very shortly.

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

> I understand that there are systems out there which have less efficient posix
> mutex implementations than Linux (which uses futexes), but I think it would
> still be worth considering to do away with the roll-your-own spinlocks on
> systems whose posix mutexes are known to behave.

If we get rid of the 'hot' spinlocks something very roughly like this
will possibly be realistic (we can't rely on pthreads, but ...). I don't
think it'll be before that.



В списке pgsql-hackers по дате отправления:

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