On 09/23/2016 02:59 PM, Pavan Deolasee wrote:
>
>
> On Fri, Sep 23, 2016 at 6:05 PM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com <mailto:tomas.vondra@2ndquadrant.com>> wrote:
>
> On 09/23/2016 05:10 AM, Amit Kapila wrote:
>
> On Fri, Sep 23, 2016 at 5:14 AM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com
> <mailto:tomas.vondra@2ndquadrant.com>> wrote:
>
> On 09/21/2016 08:04 AM, Amit Kapila wrote:
>
>
>
> (c) Although it's not visible in the results, 4.5.5 almost
> perfectly
> eliminated the fluctuations in the results. For example when
> 3.2.80 produced
> this results (10 runs with the same parameters):
>
> 12118 11610 27939 11771 18065
> 12152 14375 10983 13614 11077
>
> we get this on 4.5.5
>
> 37354 37650 37371 37190 37233
> 38498 37166 36862 37928 38509
>
> Notice how much more even the 4.5.5 results are, compared to
> 3.2.80.
>
>
> how long each run was? Generally, I do half-hour run to get
> stable results.
>
>
> 10 x 5-minute runs for each client count. The full shell script
> driving the benchmark is here: http://bit.ly/2doY6ID and in short it
> looks like this:
>
> for r in `seq 1 $runs`; do
> for c in 1 8 16 32 64 128 192; do
> psql -c checkpoint
> pgbench -j 8 -c $c ...
> done
> done
>
>
>
> I see couple of problems with the tests:
>
> 1. You're running regular pgbench, which also updates the small
> tables. At scale 300 and higher clients, there is going to heavy
> contention on the pgbench_branches table. Why not test with pgbench
> -N?
Sure, I can do a bunch of tests with pgbench -N. Good point.
But notice that I've also done the testing with Dilip's workload, and
the results are pretty much the same.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services