-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
ref(span-buffer): Introduce multiprocessed flusher #93824
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
Conversation
🔍 Existing Issues For ReviewYour pull request is modifying functions with the following pre-existing issues: 📄 File: src/sentry/spans/consumers/process/flusher.py
Did you find this useful? React with a 👍 or 👎 |
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## master #93824 +/- ##
=======================================
Coverage 88.04% 88.04%
=======================================
Files 10358 10358
Lines 598302 598361 +59
Branches 23239 23239
=======================================
+ Hits 526761 526813 +52
- Misses 71073 71080 +7
Partials 468 468 |
with metrics.timer("spans.buffer.flusher.wait_produce"): | ||
for shard in shards: | ||
with metrics.timer("spans.buffer.flusher.produce", tags={"shard": shard}): | ||
for _, flushed_segment in flushed_segments.items(): |
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.
I'm confused by this logic. This looks like you are sending the same spans to every shard?
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.
yeah this is nonsense... leftover from a prev version
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.
The backpressure and healthy signals could be reduced to one per process. Other than that, LGTM
Refs STREAM-266
Compression helped a lot bring the time on the main thread down. We now think we can scale down the consumers. However, we also need to ensure the flusher can keep up. So let's make the flusher spawn a process per redis shard.
We think this is easier to do than making the process_spans/insert_spans multiprocessed. Over time we can offload mroe things like statistics/metrics to the flusher, and keep the main thread minimal.