Re: Speed up Clog Access by increasing CLOG buffers - Mailing list pgsql-hackers

From Jim Nasby
Subject Re: Speed up Clog Access by increasing CLOG buffers
Date
Msg-id 956b695d-f6c5-d652-bf0c-cea95981547c@BlueTreble.com
Whole thread Raw
In response to Re: Speed up Clog Access by increasing CLOG buffers  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: Speed up Clog Access by increasing CLOG buffers  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
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).
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)   mobile: 512-569-9461



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: sequential scan result order vs performance
Next
From: Jim Nasby
Date:
Subject: Re: make coverage-html on OS X