-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Add commit proxy long-running commit request tracing #12152
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
Draft
kakaiu
wants to merge
2
commits into
apple:main
Choose a base branch
from
kakaiu:visibility-long-commit
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Draft
+122
−2
Conversation
This file contains hidden or 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
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-clang-ide on Linux RHEL 9
|
Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-clang-arm on Linux CentOS 7
|
Result of foundationdb-pr-macos on macOS Ventura 13.x
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-cluster-tests on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr-clang on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
Result of foundationdb-pr on Linux RHEL 9
|
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.
We aim to understand the root cause of peak commit latency in the cluster—a challenging problem. At first, we want to identify which components are contributing most to the performance degradation, such as the network, CPU, tLogs, or resolvers.
This PR addresses this question by tracing long-running requests (those exceeding 0.5 seconds). Specifically, when a commit request arrives at a commit proxy (CP), the CP records the latency for each step in the request's processing. If the total serving time of the request exceeds the threshold, the CP tracks it accordingly.
The key idea of the role based approach is that: each role provides a "service". Those roles work together to provide some functionality like transaction commit. A commit slow down eventually can be explained by slow down of some services or the network.
Notably, we do not attempt to log every individual long-running request, as the volume of such requests can be substantial. Instead, our focus is on identifying which commit step is the "bottleneck".
Bottleneck Definition:
For a given set of long-running commit requests, a step is the bottleneck if and only if its removal would yield the greatest reduction in the total time span of those requests.
To identify the bottleneck step, the CP aggregates the latency of each step across all slow requests and generates a trace event every 10 seconds. The aggregation algorithm for a step's time span simply sums the durations of that step across all long-running requests observed in the past 10 seconds. The aggregated time span represents the cumulative time that the step was actively executing, reflecting its probability of blocking other steps within that period.
To minimize the overhead associated with latency tracking at each step, we leverage shared_ptr to avoid unnecessary memory copies and employ inline functions to eliminate function call overhead. We avoid passing any metrics over the network to save bandwidth.
Why don't we sum up all requests in the last 10 seconds?
Here, we assume that there is a "correlation" between long-running commits and specific commit steps. By filtering out fast commits, we effectively remove noise introduced by their shorter durations. For example, if the majority of commits in the last 10 seconds are completed quickly while only a few are long-running, aggregating all commit steps—including the fast ones—can obscure the visibility of the slow steps. This is because the cumulative time of fast commits can overwhelm the contribution of the long-running steps, masking potential bottlenecks.
Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
release-branch
ormain
if this is the youngest branch)