On 10/31/2016 05:01 AM, Jim Nasby wrote:
On 10/30/16 1:32 PM, Tomas Vondra wrote:
Now, maybe this has nothing to do with PostgreSQL itself, but maybe it's
some sort of CPU / OS scheduling artifact. For example, the system has
36 physical cores, 72 virtual ones (thanks to HT). I find it strange
that the "good" client counts are always multiples of 72, while the
"bad" ones fall in between.
72 = 72 * 1 (good)
108 = 72 * 1.5 (bad)
144 = 72 * 2 (good)
180 = 72 * 2.5 (bad)
216 = 72 * 3 (good)
252 = 72 * 3.5 (bad)
288 = 72 * 4 (good)
So maybe this has something to do with how OS schedules the tasks, or
maybe some internal heuristics in the CPU, or something like that.
It might be enlightening to run a series of tests that are 72*.1 or *.2
apart (say, 72, 79, 86, ..., 137, 144).
Yeah, I've started a benchmark with client a step of 6 clients
36 42 48 54 60 66 72 78 ... 252 258 264 270 276 282 288
instead of just
36 72 108 144 180 216 252 288
which did a test every 36 clients. To compensate for the 6x longer runs,
I'm only running tests for "group-update" and "master", so I should have
the results in ~36h.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
