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