Re: [HACKERS] kqueue

On Fri, Dec 20, 2019 at 12:41 PM Rui DeSousa <rui(at)crazybean(dot)net> wrote:
> I’m instrested in the kqueue patch and would like to know its current state and possible timeline for inclusion in the base code. I have several large FreeBSD systems running PostgreSQL 11 that I believe currently displays this issue. The system has 88 vCPUs, 512GB Ram, and very active application with over 1000 connections to the database. The system exhibits high kernel CPU usage servicing poll() for connections that are idle.

Hi Rui,

It's still my intention to get this committed eventually, but I got a
bit frazzled by conflicting reports on several operating systems. For
FreeBSD, performance was improved in many cases, but there were also
some regressions that seemed to be related to ongoing work in the
kernel that seemed worth waiting for. I don't have the details
swapped into my brain right now, but there was something about a big
kernel lock for Unix domain sockets which possibly explained some
local pgbench problems, and there was also a problem relating to
wakeup priority with some test parameters, which I'd need to go and
dig up. If you want to test this and let us know how you get on,
that'd be great! Here's a rebase against PostgreSQL's master branch,
and since you mentioned PostgreSQL 11, here's a rebased version for
REL_11_STABLE in case that's easier for you to test/build via ports or
whatever and test with your production workload (eg on a throwaway
copy of your production system). You can see it's working by looking
in top: instead of state "select" (which is how poll() is reported)
you see "kqread", which on its own isn't exciting enough to get this
committed :-)

PS Here's a list of slow burner PostgreSQL/FreeBSD projects:
https://wiki.postgresql.org/wiki/FreeBSD