Horton

Re: [HACKERS] kqueue

Matteo Beccati <php@beccati.com>

View thread View on postgr.es
From: Matteo Beccati <php@beccati.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Andres Freund <andres@anarazel.de>, Mateusz Guzik <mjguzik@gmail.com>, Keith Fiske <keith@omniti.com>, Tom Lane <tgl@sss.pgh.pa.us>, Heikki Linnakangas <hlinnaka@iki.fi>, Marko Tiikkaja <marko@joh.to>, Alvaro Herrera <alvherre@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2018-10-01T17:25:45Z
Lists: pgsql-hackers 
Hi Thomas,

On 01/10/2018 01:09, Thomas Munro wrote:
> I don't know why the existence of the kqueue should make recvfrom()
> slower on the pgbench side.  That's probably something to look into
> off-line with some FreeBSD guru help.  Degraded performance for
> clients on the same machine does seem to be a show stopper for this
> patch for now.  Thanks for testing!

Glad to be helpful!

I've tried running pgbench from a separate VM and in fact kqueue 
consistently takes the lead with 5-10% more tps on select/prepared 
pgbench on NetBSD too.

What I have observed is that sys cpu usage is ~65% (35% idle) with 
kqueue, while unpatched master averages at 55% (45% idle): relatively 
speaking that's almost 25% less idle cpu available for a local pgbench 
to do its own stuff.

Running pgbench locally shows an average 47% usr / 53% sys cpu 
distribution w/ kqueue vs more like 50-50 w/ vanilla, so I'm inclined to 
think that's the reason why we see a performance drop instead. Thoguhts?


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Commits

  1. Add kqueue(2) support to the WaitEventSet API.

  2. Add WL_EXIT_ON_PM_DEATH pseudo-event.

  3. Be conservative about alignment requirements of struct epoll_event.

  4. Make idle backends exit if the postmaster dies.