Re: Excessive PostmasterIsAlive calls slow down WAL redo

On April 9, 2018 6:36:19 PM PDT, Thomas Munro <thomas.munro@enterprisedb.com> 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.

We still create a lot of WES adhoc in a number of places. I don't think this would solve that?  The problem isn't that
IsAliveis expensive, it's that polling is expensive. It's possible that using kqueue would fix that, because the
highestfrequency cases use a persistent WES. 

Andres

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.