From: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Date: | 2018-04-10 01:36:19 |
Message-ID: | CAEepm=05UOn=NZcNuk-GpBu10TvoAdXsQdB+A-60tHA66cmxdg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Thomas Munro
http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-04-10 01:40:37 | Re: Excessive PostmasterIsAlive calls slow down WAL redo |
Previous Message | Andres Freund | 2018-04-10 01:34:31 | Re: Excessive PostmasterIsAlive calls slow down WAL redo |