Re: Excessive PostmasterIsAlive calls slow down WAL redo

On April 9, 2018 6:36:19 PM PDT, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>On Tue, Apr 10, 2018 at 12:53 PM, Andres Freund <andres(at)anarazel(dot)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 IsAlive is expensive, it's that polling is expensive. It's possible that using kqueue would fix that, because the highest frequency cases use a persistent WES.

Andres

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