On 09/17/2016 07:05 AM, Amit Kapila wrote:
On Sat, Sep 17, 2016 at 9:17 AM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
On 09/14/2016 05:29 PM, Robert Haas wrote:
...
Sure, but you're testing at *really* high client counts here.
Almost nobody is going to benefit from a 5% improvement at 256
clients. You need to test 64 clients and 32 clients and 16
clients and 8 clients and see what happens there. Those cases are
a lot more likely than these stratospheric client counts.
Right. My impression from the discussion so far is that the patches
only improve performance with very many concurrent clients - but as
Robert points out, almost no one is running with 256 active
clients, unless they have 128 cores or so. At least not if they
value latency more than throughput.
See, I am also not in favor of going with any of these patches, if
they doesn't help in reduction of contention. However, I think it is
important to understand, under what kind of workload and which
environment it can show the benefit or regression whichever is
applicable.
Sure. Which is why I initially asked what type of workload should I be
testing, and then done the testing with multiple savepoints as that's
what you suggested. But apparently that's not a workload that could
benefit from this patch, so I'm a bit confused.
Just FYI, couple of days back one of EDB's partner who was doing the
performance tests by using HammerDB (which is again OLTP focussed
workload) on 9.5 based code has found that CLogControlLock has the
significantly high contention. They were using synchronous_commit=off
in their settings. Now, it is quite possible that with improvements
done in 9.6, the contention they are seeing will be eliminated, but
we have yet to figure that out. I just shared this information to you
with the intention that this seems to be a real problem and we should
try to work on it unless we are able to convince ourselves that this
is not a problem.
So, can we approach the problem from this direction instead? That is,
instead of looking for workloads that might benefit from the patches,
look at real-world examples of CLOG lock contention and then evaluate
the impact on those?
Extracting the workload from benchmarks probably is not ideal, but it's
still better than constructing the workload on our own to fit the patch.
FWIW I'll do a simple pgbench test - first with synchronous_commit=on
and then with synchronous_commit=off. Probably the workloads we should
have started with anyway, I guess.
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
