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
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 |