Re: track_planning causing performance regression

Поиск
Список
Период
Сортировка
От Ants Aasma
Тема Re: track_planning causing performance regression
Дата
Msg-id CANwKhkPUBcSBMwR1=dgGe-7cZriQ=Rge4j_xv5wHni+YM_CgSA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: track_planning causing performance regression  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: track_planning causing performance regression  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Re: track_planning causing performance regression  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Дерево обсуждения
On Tue, 30 Jun 2020 at 08:43, Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
> The problem looks to be that spinlocks are terrible with overloaded CPU and a contended spinlock. A process holding the spinlock might easily get scheduled out leading to excessive spinning by everybody. I think a simple thing to try would be to replace the spinlock with LWLock.

Yes. Attached is the POC patch that replaces per-counter spinlock with LWLock.

Great. I think this is the one that should get considered for testing.
 
> I did a prototype patch that replaces spinlocks with futexes, but was not able to find a workload where it mattered.

I'm not familiar with futex, but could you tell me why you used futex instead
of LWLock that we already have? Is futex portable?

Futex is a Linux kernel call that allows to build a lock that has uncontended cases work fully in user space almost exactly like a spinlock, while falling back to syscalls that wait for wakeup in case of contention. It's not portable, but probably something similar could be implemented for other operating systems. I did not pursue this further because it became apparent that every performance critical spinlock had already been removed.

To be clear, I am not advocating for this patch to get included. I just had the patch immediately available and it could have confirmed that using a better lock fixes things.
-- 
Ants Aasma
Senior Database Engineer
www.cybertec-postgresql.com

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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Use of "long" in incremental sort code
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions