Re: Excessive PostmasterIsAlive calls slow down WAL redo

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Excessive PostmasterIsAlive calls slow down WAL redo
Дата
Msg-id 95b9a140-04ef-0db4-62c7-2a38d983aff6@iki.fi
обсуждение исходный текст
Ответ на Re: Excessive PostmasterIsAlive calls slow down WAL redo  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: Excessive PostmasterIsAlive calls slow down WAL redo  (Thomas Munro <thomas.munro@enterprisedb.com>)
Re: Excessive PostmasterIsAlive calls slow down WAL redo  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
On 10/04/18 04:36, Thomas Munro wrote:
> On Tue, Apr 10, 2018 at 12:53 PM, Andres Freund <andres@anarazel.de> wrote:
>> I coincidentally got pinged about our current approach causing
>> performance problems on FreeBSD and started writing a patch.  The
>> problem there appears to be that constantly attaching events to the read
>> pipe end, from multiple processes, causes significant contention inside
>> the kernel. Which isn't that surprising.   That's distinct from the
>> problem netbsd/openbsd reported a while back (superflous wakeups).
>>
>> That person said he'd work on adding an equivalent of linux'
>> prctl(PR_SET_PDEATHSIG) to FreeBSD.
> 
> Just an idea, not tested: what about a reusable WaitEventSet with zero
> timeout?  Using the kqueue patch, that'd call kevent() which'd return
> immediately and tell you if any postmaster death notifications had
> arrive on your queue since last time you asked.  It doesn't even touch
> the pipe, or any other kernel objects apart from your own queue IIUC.

Hmm. In PostmasterIsAlive(), you'd still need to call kevent() to check 
if postmaster has died. It would just replace the current read() syscall 
on the pipe with the kevent() syscall. Is it faster?

- Heikki


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

Предыдущее
От: Jeevan Chalke
Дата:
Сообщение: Re: [sqlsmith] Failed assertion in create_gather_path
Следующее
От: Bruce Momjian
Дата:
Сообщение: 'make check' fails