On Fri, Mar 10, 2017 at 8:19 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Wed, Feb 22, 2017 at 2:01 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I don't think I know enough about the serializable code to review
>> this, or at least not quickly, but it seems very cool if it works.
>> Have you checked what effect it has on shared memory consumption?
>
> I'm not sure how to test that. Kevin, can you provide any pointers to
> the test workloads you guys used when developing SSI?
During development there was first and foremost the set of tests
which wound up implemented in the isolation testing environment
developed by Heikki, although for most of the development cycle
these tests were run by a python tool written by Markus Wanner
(which was not as fast as Heikki's C-based tool, but provided a lot
more detail in case of failure -- so it was very nice to have until
we got down to polishing things).
The final stress test to chase out race conditions and the
performance benchmarks were all run by Dan Ports on big test
machines at MIT. I'm not sure how much I can say to elaborate on
what is in section 8 of this paper:
http://vldb.org/pvldb/vol5/p1850_danrkports_vldb2012.pdf
I seem to remember that he had some saturation run versions of the
"DBT-2++" tests, modified to monitor for serialization anomalies
missed by the implementation, which he sometimes ran for days at a
time on MIT testing machines. There were some very narrow race
conditions uncovered by this testing, which at high concurrency on a
16 core machine might hit a particular problem less often than once
per day.
I also remember that both Anssi Kääriäinen and Yamamoto Takahashi
did a lot of valuable testing of the patch and found problems that
we had missed. Perhaps they can describe their testing or make
other suggestions.
--
Kevin Grittner
