-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
kv/concurrency: compute contention event duration from (key,txn) wait start time #99166
kv/concurrency: compute contention event duration from (key,txn) wait start time #99166
Conversation
… start time Fixes cockroachdb#98104. This commit resolves the bug identified in cockroachdb#98104 where multiple contention events could be emitted with overlapping durations, such that when these durations were added together (e.g. by `GetCumulativeContentionTime`), their sum was larger than the runtime of the entire query. This was possible because as of 70ef641, we were failing to reset the waiting start time on each new lock holder transaction for the same key. This commit fixes this by computing the contention event duration using `contentionTag.waitStart` instead of `waitingState.lockWaitStart`. It also cleans up some of this code and makes it harder to make such a mistake in the future. Release note: None
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @AlexTalks and @nvanbenschoten)
pkg/kv/kvserver/concurrency/lock_table_waiter_test.go
line 953 at r1 (raw file):
var events []*kvpb.ContentionEvent h := newContentionEventTracer(sp, clock)
wanna take the opportunity to make this take an hlc.WallClock
instead of *hlc.Clock
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @AlexTalks and @nvanbenschoten)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TFTR!
bors r=andreimatei
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @AlexTalks and @andreimatei)
pkg/kv/kvserver/concurrency/lock_table_waiter_test.go
line 953 at r1 (raw file):
Previously, andreimatei (Andrei Matei) wrote…
wanna take the opportunity to make this take an
hlc.WallClock
instead of*hlc.Clock
?
+1 on the idea, but I need to backport this all the way to release-22.1 and I suspect that such a refactor will make that more difficult, so I'll save it for another PR.
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed: |
bors r=andreimatei |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build failed (retrying...): |
Build succeeded: |
Encountered an error creating backports. Some common things that can go wrong:
You might need to create your backport manually using the backport tool. error creating merge commit from 1201c01 to blathers/backport-release-22.1-99166: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.1.x failed. See errors above. error creating merge commit from 1201c01 to blathers/backport-release-22.2-99166: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict [] you may need to manually resolve merge conflicts with the backport tool. Backport to branch 22.2.x failed. See errors above. 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
Fixes #98104.
This commit resolves the bug identified in #98104 where multiple contention events could be emitted with overlapping durations, such that when these durations were added together (e.g. by
GetCumulativeContentionTime
), their sum was larger than the runtime of the entire query. This was possible because as of 70ef641, we were failing to reset the waiting start time on each new lock holder transaction for the same key.This commit fixes this by computing the contention event duration using
contentionTag.waitStart
instead ofwaitingState.lockWaitStart
. It also cleans up some of this code and makes it harder to make such a mistake in the future.Release note: None