Accumulation of old entries in the underlying array backing the
entries slice has been found to cause massive memory growth in
CockroachDB for workloads that do large (1MB) writes
(https://github.com/cockroachdb/cockroach/issues/14776)
This doesn't appear to have much consistent effect on the raft
benchmarks, although it's worth noting that they vary quite a bit
between runs so it's kind of tough to draw strong conclusions from them.
Let me know if there are any different benchmarks you'd like me to run!
Fixes#7746
benchmark old ns/op new ns/op delta
BenchmarkOneNode-8 3283 3125 -4.81%
benchmark old allocs new allocs delta
BenchmarkOneNode-8 6 6 +0.00%
benchmark old bytes new bytes delta
BenchmarkOneNode-8 796 727 -8.67%
benchmark old ns/op new ns/op delta
BenchmarkProposal3Nodes-8 4269 4337 +1.59%
benchmark old allocs new allocs delta
BenchmarkProposal3Nodes-8 15 13 -13.33%
benchmark old bytes new bytes delta
BenchmarkProposal3Nodes-8 5839 4544 -22.18%
stableTo should only mark the index stable if the term is matched. After raft sends out unstable
entries to application, raft makes progress without waiting for reply. When the appliaction
calls the stableTo to notify the entries up to "index" are stable, raft might have truncated
some entries before "index" due to leader lost. raft must verify the (index,term) of stableTo,
before marking the entries as stable.
GhostComputing