-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
fix(buffers): make LimitedSender/LimitedReceiver wake up correctly #11741
Conversation
Signed-off-by: Toby Lawrence <toby@nuclearfurnace.com>
✔️ Deploy Preview for vector-project ready! 🔨 Explore the source changes: 792bb13 🔍 Inspect the deploy log: https://app.netlify.com/sites/vector-project/deploys/62281e89bf1f89000840cac7 😎 Browse the preview: https://deploy-preview-11741--vector-project.netlify.app |
Soak Test ResultsBaseline: d06ee2a ExplanationA soak test is an integrated performance test for vector in a repeatable rig, with varying configuration for vector. What follows is a statistical summary of a brief vector run for each configuration across SHAs given above. The goal of these tests are to determine, quickly, if vector performance is changed and to what degree by a pull request. Where appropriate units are scaled per-core. The table below, if present, lists those experiments that have experienced a statistically significant change in their throughput performance between baseline and comparision SHAs, with 90.0% confidence OR have been detected as newly erratic. Negative values mean that baseline is faster, positive comparison. Results that do not exhibit more than a ±5% change in mean throughput are discarded. An experiment is erratic if its coefficient of variation is greater than 0.3. The abbreviated table will be omitted if no interesting changes are observed. No interesting changes in throughput with confidence ≥ 90.00% and absolute Δ mean >= ±5%: Fine details of change detection per experiment.
Fine details of each soak run.
|
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.
Ah ha. Nice work.
As mentioned in #11633, the introduction of
LimitedSender
/LimitedReceiver
coincided with some soak tests become flaky, due to Vector itself actually locking up.After further investigation, it turns out that the wakeup mechanism used for the writer-to-reader wakeups was not implemented correctly. Using
AtomicWaker
, I incorrectly read the internal code and believed that a wake-up would be stored even if a waker was not yet registered... which was an incorrect understanding.This PR switches over to using
PollNotify
for both the writer and reader wakeups instead, as it's based on the robustNotify
type fromtokio::sync
which is high-quality and correctly tested underloom
.Practically speaking, it appears to fix the issue of Vector locking up when rerunning the reproduction steps listed out in the aforementioned issue.
Fixes #11633.