On 6/3/20 9:33 PM, Peter Geoghegan wrote:
> 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.
The test will do that automatically for you now. :)
> It doesn't always
> fail, but it fails often enough.
Hey, that's good!
> 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 ***
Aw shucks, you left out the good part! I'm guessing the workload returned
{:valid? false} here?
> 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.
Try out 21ae84ed: I added a --prepare-threshold option for you. :)
--Kyle
