release-23.1: kvserver: eagerly extend expiration leases in Raft scheduler #100686
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks for opening a backport. Please check the backport criteria before merging:
If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.
Add a brief release justification to the body of your PR to justify this backport. Some other things to consider:
|
|
This change is |
nicktrav
approved these changes
Apr 5, 2023
The store lease renewer, which eagerly extends expiration-based leases, did not correctly (un)register ranges on splits/merges/relocations. This could cause the lease renewer to not eagerly extend leases for some ranges, but was mitigated by the lease renewer only being used for the meta and liveness ranges which rarely/never split. This patch makes sure the lease renewer is notified on these events. It also incidentally fixes an unlikely race where a range split immediately following an expiration-based lease transfer could leave the RHS using an expiration-based lease until it was transferred elsewhere. Epic: none Release note: None
This patch prevents quiescence with expiration-based leases, since we'll have to propose a lease extension shortly anyway. Out of caution, we only do this when `kv.expiration_leases_only.enabled` is `true`, with an eye towards 23.1 backports. For 23.2, we will always do this. Epic: none Release note: None
This patch eagerly extends expiration leases in the Raft scheduler, during Raft ticks, but only if `kv.expiration_leases_only.enabled` is `true`. This is possible because we no longer allow ranges with expiration leases to quiesce in this case. The old store lease renewer is disabled in this case, but still tracks local system ranges with expiration leases in case the setting is later changed. The store lease renewer is still retained for use by default, to allow backporting this change to 23.1 while keeping the existing default behavior. Doing this during Raft scheduling is compelling, since it already does efficient goroutine scheduling (including liveness range prioritization) and holds the replica mutex. Compared to an alternative implementation that relied on a separate, improved store lease renewer which also allowed ranges to quiesce between extensions, this has significantly better performance. The main reason for this is that unquiescing involves a Raft append to wake the leader. On an idle cluster with 20.000 ranges using only expiration leases, CPU usage was 26% vs. 30%, write IOPS was 500 vs. 900, and network traffic was 0.8 MB/s vs. 1.0 MB/s. KV benchmark results: ``` name old ops/sec new ops/sec delta kv0/enc=false/nodes=3 14.6k ± 3% 15.2k ± 4% +3.72% (p=0.003 n=8+8) kv95/enc=false/nodes=3 30.6k ± 3% 32.2k ± 3% +5.22% (p=0.000 n=8+8) name old p50 new p50 delta kv0/enc=false/nodes=3 11.3 ± 3% 11.0 ± 0% -2.76% (p=0.006 n=8+6) kv95/enc=false/nodes=3 4.59 ± 8% 4.55 ± 3% ~ (p=0.315 n=8+8) name old p95 new p95 delta kv0/enc=false/nodes=3 31.5 ± 0% 30.2 ± 4% -4.25% (p=0.003 n=6+8) kv95/enc=false/nodes=3 19.5 ± 7% 18.1 ± 4% -7.28% (p=0.000 n=8+7) name old p99 new p99 delta kv0/enc=false/nodes=3 48.7 ± 3% 47.4 ± 6% ~ (p=0.059 n=8+8) kv95/enc=false/nodes=3 32.8 ± 9% 30.2 ± 4% -8.04% (p=0.001 n=8+8) ``` Epic: none Release note: None
Previously, the replicate queue would only reacquire epoch leases, and allow expiration leases to expire. It now reacquires all leases, since they are eagerly extended. In the future, when quiescence is removed entirely, this responsibility should be moved to the Raft tick loop. Epic: none Release note: None
If `kv.expiration_leases_only.enabled´ is `true`, this patch disables expiration lease extension during request processing, since the Raft scheduler will eagerly extend leases in this case. This will eventually be removed completely, but is kept for now with an eye towards a 23.1 backport. Epic: none Release note: None
The store lease renewer begins tracking an system range's expiration-based lease for renewal when it's first applied. However, it only did this if the lease was still valid when first applied. It was possible for the node to apply a lease after it's lapsed, but then to retain and extend the lease, and in this case it would not be registered with the lease renewer. Epic: none Release note: None
erikgrinaker
force-pushed
the
backport23.1-100392-100430
branch
from
fa0700a
to
f2c384f
Compare
Epic: none Release note: None
erikgrinaker
force-pushed
the
backport23.1-100392-100430
branch
from
f2c384f
to
27030bf
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport:
TestLeaseRenewer" (kvserver: deflakeTestLeaseRenewer#101012)Please see individual PRs for details.
/cc @cockroachdb/release
Release justification: fixes rangefeed resolved timestamps with expiration leases, gated behind default-off cluster setting.