Re: kqueue
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Marko Tiikkaja <marko@joh.to>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2016-09-13T15:32:54Z
Lists: pgsql-hackers
Hi, On 2016-09-13 16:08:39 +0300, Heikki Linnakangas wrote: > So, if I've understood correctly, the purpose of this patch is to improve > performance on a multi-CPU system, which has the kqueue() function. Most > notably, FreeBSD? I think it's not necessarily about the current system, but more about future uses of the WaitEventSet stuff. Some of that is going to use a lot more sockets. E.g. doing a parallel append over FDWs. > I launched a FreeBSD 10.3 instance on Amazon EC2 (ami-e0682b80), on a > m4.10xlarge instance. That's a 40 core system, biggest available, I believe. > I built PostgreSQL master on it, and ran pgbench to benchmark: > > pgbench -i -s 200 postgres > pgbench -M prepared -j 36 -c 36 -S postgres -T20 -P1 This seems likely to actually seldomly exercise the relevant code path. We only do the poll()/epoll_wait()/... when a read() doesn't return anything, but that seems likely to seldomly occur here. Using a lower thread count and a lot higher client count might change that. Note that the case where poll vs. epoll made a large difference (after the regression due to ac1d7945f86) on linux was only on fairly large machines, with high clients counts. Greetings, Andres Freund
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