> Mengxing Liu wrote:
>> The CPU utilization of CheckForSerializableConflictOut/In is
>> 0.71%/0.69%.
How many cores were on the system used for this test? The paper
specifically said that they didn't see performance degradation on
the PostgreSQL implementation until 32 concurrent connections with
24 or more cores. The goal here is to fix *scaling* problems. Be
sure you are testing at an appropriate scale. (The more sockets,
cores, and clients, the better, I think.)
On Fri, Jun 2, 2017 at 10:08 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> Kevin mentioned during PGCon that there's a paper by some group in
> Sydney that developed a benchmark on which this scalability
> problem showed up very prominently.
https://pdfs.semanticscholar.org/6c4a/e427e6f392b7dec782b7a60516f0283af1f5.pdf
"[...] we see a much better scalability of pgSSI than the
corresponding implementations on InnoDB. Still, the overhead of
pgSSI versus standard SI increases significantly with higher MPL
than one would normally expect, reaching around 50% with MPL 128."
"Our profiling showed that PostgreSQL spend 2.3% of the overall
runtime in traversing these list, plus 10% of its runtime waiting on
the corresponding kernel mutexes."
If you cannot duplicate their results, you might want to contact the
authors for more details on their testing methodology.
Note that the locking around access to the list is likely to be a
bigger problem than the actual walking and manipulation of the list
itself.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/