On 09/23/2016 05:10 AM, Amit Kapila wrote:
On Fri, Sep 23, 2016 at 5:14 AM, Tomas Vondra
<tomas.von...@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
It of course begs the question what kernel version is running on
the machine used by Dilip (i.e. cthulhu)? Although it's a Power
machine, so I'm not sure how much the kernel matters on it.
cthulhu is a x86 m/c and the kernel version is 3.10. Seeing, the
above results I think kernel version do matter, but does that mean
we ignore the benefits we are seeing on somewhat older kernel
version. I think right answer here is to do some experiments which
can show the actual contention as suggested by Robert and you.
Yes, I think it'd be useful to test a new kernel version. Perhaps try
4.5.x so that we can compare it to my results. Maybe even try using my
shell script
There are results for 64, 128 and 192 clients. Why should we care
about numbers in between? How likely (and useful) would it be to
get improvement with 96 clients, but no improvement for 64 or 128
clients?
>>
The only point to take was to see from where we have started seeing
improvement, saying that the TPS has improved from >=72 client count
is different from saying that it has improved from >=128.
I find the exact client count rather uninteresting - it's going to be
quite dependent on hardware, workload etc.
>>
I don't dare to suggest rejecting the patch, but I don't see how
we could commit any of the patches at this point. So perhaps
"returned with feedback" and resubmitting in the next CF (along
with analysis of improvedworkloads) would be appropriate.
Agreed with your conclusion and changed the status of patch in CF
accordingly.
+1
--
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
