On Wed, Jun 3, 2020 at 4:26 PM Kyle Kingsbury <aphyr@jepsen.io> wrote:
> Oh this is interesting! I can say that I'm running on a 24-way Xeon with 128gb of ram, so running out of system
memorydoesn't immediately seem like a bottleneck--I'd suspect my config runs slower by dint of disks (older SSD), fs
settings,or maybe postgres tuning (this is with the stock Debian config files).
I can now get it to run fairly consistently, now that I know to
consistently truncate all three tables between runs. It doesn't always
fail, but it fails often enough. And it doesn't seem to matter that my
local Postgres is so much faster, or has fewer failures. For example,
I now see the following failure on Postgres 13:
INFO [2020-06-03 18:26:50,706] jepsen test runner - jepsen.core {:perf
{:latency-graph {:valid? true},
:rate-graph {:valid? true},
:valid? true},
:clock {:valid? true},
:stats
{:valid? true,
:count 30049,
:ok-count 26792,
:fail-count 3200,
:info-count 57,
:by-f
{:txn
{:valid? true,
:count 30049,
:ok-count 26792,
:fail-count 3200,
:info-count 57}}},
:exceptions {:valid? true},
:workload
*** SNIP ***
Kyle: Could you figure out a way of setting "prepareThreshold=0" in
JDBC (i.e. disable prepared statements), please? That would make it a
bit easier to debug.
--
Peter Geoghegan
