Re: kqueue
Thomas Munro <thomas.munro@enterprisedb.com>
From: Thomas Munro <thomas.munro@enterprisedb.com>
To: Keith Fiske <keith@omniti.com>
Cc: Matteo Beccati <php@beccati.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, 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: 2016-09-14T23:04:15Z
Lists: pgsql-hackers
On Thu, Sep 15, 2016 at 10:48 AM, Keith Fiske <keith@omniti.com> wrote: > Thomas Munro brought up in #postgresql on freenode needing someone to test a > patch on a larger FreeBSD server. I've got a pretty decent machine (3.1Ghz > Quad Core Xeon E3-1220V3, 16GB ECC RAM, ZFS mirror on WD Red HDD) so offered > to give it a try. > > Bench setup was: > pgbench -i -s 100 -d postgres > > I ran this against 96rc1 instead of HEAD like most of the others in this > thread seem to have done. Not sure if that makes a difference and can re-run > if needed. > With higher concurrency, this seems to cause decreased performance. You can > tell which of the runs is the kqueue patch by looking at the path to > pgbench. Thanks Keith. So to summarise, you saw no change with 1 client, but with 4 clients you saw a significant drop in performance (~93K TPS -> ~80K TPS), and a smaller drop for 64 clients (~72 TPS -> ~68K TPS). These results seem to be a nail in the coffin for this patch for now. Thanks to everyone who tested. I might be back in a later commitfest if I can figure out why and how to fix it. -- Thomas Munro http://www.enterprisedb.com
Commits
-
Add kqueue(2) support to the WaitEventSet API.
- 815c2f0972c8 13.0 landed
-
Add WL_EXIT_ON_PM_DEATH pseudo-event.
- cfdf4dc4fc96 12.0 cited
-
Be conservative about alignment requirements of struct epoll_event.
- a3b30763cc86 9.6.0 cited
-
Make idle backends exit if the postmaster dies.
- ac1d7945f866 9.6.0 cited