Re: kqueue

From: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
To: Keith Fiske <keith(at)omniti(dot)com>
Cc: Matteo Beccati <php(at)beccati(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Marko Tiikkaja <marko(at)joh(dot)to>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: kqueue
Date: 2016-09-28 21:39:19
Message-ID: CAEepm=0BTcqXNESjs_TMGdiFQTTiX4JGFu+TcZpW2bPX-e2XqA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 29, 2016 at 9:09 AM, Keith Fiske <keith(at)omniti(dot)com> wrote:
> On Thu, Sep 15, 2016 at 11:11 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> Ok, here's a version tweaked to use EVFILT_PROC for postmaster death
>> detection instead of the pipe, as Tom Lane suggested in another
>> thread[1].
>>
>> [...]
>
> Ran benchmarks on unaltered 96rc1 again just to be safe. Those are first.
> Decided to throw a 32 process test in there as well to see if there's
> anything going on between 4 and 64

Thanks! A summary:

┌──────────────────┬─────────┬───────────┬────────────────────┬───────────┐
│ code │ clients │ average │ standard_deviation │ median │
├──────────────────┼─────────┼───────────┼────────────────────┼───────────┤
│ 9.6rc1 │ 1 │ 25704.923 │ 108.766 │ 25731.006 │
│ 9.6rc1 │ 4 │ 94032.889 │ 322.562 │ 94123.436 │
│ 9.6rc1 │ 32 │ 86647.401 │ 33.616 │ 86664.849 │
│ 9.6rc1 │ 64 │ 79360.680 │ 1217.453 │ 79941.243 │
│ 9.6rc1/kqueue-v6 │ 1 │ 24569.683 │ 1433.339 │ 25146.434 │
│ 9.6rc1/kqueue-v6 │ 4 │ 93435.450 │ 50.214 │ 93442.716 │
│ 9.6rc1/kqueue-v6 │ 32 │ 88000.328 │ 135.143 │ 87891.856 │
│ 9.6rc1/kqueue-v6 │ 64 │ 71726.034 │ 4784.794 │ 72271.146 │
└──────────────────┴─────────┴───────────┴────────────────────┴───────────┘

┌─────────┬───────────┬───────────┬──────────────────────────┐
│ clients │ unpatched │ patched │ percent_change │
├─────────┼───────────┼───────────┼──────────────────────────┤
│ 1 │ 25731.006 │ 25146.434 │ -2.271858317548874692000 │
│ 4 │ 94123.436 │ 93442.716 │ -0.723220516514080510000 │
│ 32 │ 86664.849 │ 87891.856 │ 1.415807001521458833000 │
│ 64 │ 79941.243 │ 72271.146 │ -9.594668173973727179000 │
└─────────┴───────────┴───────────┴──────────────────────────┘

The variation in the patched 64 client numbers is quite large, ranging
from ~66.5k to ~79.5k. The highest number matched the unpatched
numbers which ranged 77.9k to 80k. I wonder if that is noise and we
need to run longer (in which case the best outcome might be 'this
patch is neutral on FreeBSD'), or if something the patch does is doing
is causing that (for example maybe EVFILT_PROC proc filters causes
contention on the process table lock).

Matteo's results with the v6 patch on a low end NetBSD machine were
not good. But the report at [1] implies that larger NetBSD and
OpenBSD systems have terrible problems with the
poll-postmaster-alive-pipe approach, which this EVFILT_PROC approach
would seem to address pretty well.

It's difficult to draw any conclusions at this point.

[1] https://www.postgresql.org/message-id/flat/20160915135755.GC19008%40genua.de

--
Thomas Munro
http://www.enterprisedb.com

In response to

  • Re: kqueue at 2016-09-28 20:09:02 from Keith Fiske

Responses

  • Re: kqueue at 2016-10-11 07:08:21 from Torsten Zuehlsdorff

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-09-28 21:39:48 Re: Showing parallel status in \df+
Previous Message Tom Lane 2016-09-28 21:22:32 Re: Set log_line_prefix and application name in test drivers