On Fri, Dec 20, 2019 at 12:41 PM Rui DeSousa <r...@crazybean.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
0001-Add-kqueue-2-support-for-WaitEventSet-v13.patch
Description: Binary data
0001-Add-kqueue-2-support-for-WaitEvent-v13-REL_11_STABLE.patch
Description: Binary data
