-
Notifications
You must be signed in to change notification settings - Fork 969
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
Enable concurrent write to both stage files and object storage to get 5GB/s write throughput #4743
Conversation
603b538
to
40ee01c
Compare
This modification may impact the performance in small file scenarios, which are the main focus of write-back optimization. |
Then, we expanded |
40ee01c
to
3f64165
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #4743 +/- ##
===========================================
+ Coverage 25.01% 63.38% +38.37%
===========================================
Files 25 24 -1
Lines 16011 15906 -105
===========================================
+ Hits 4005 10082 +6077
+ Misses 11518 4435 -7083
- Partials 488 1389 +901 ☔ View full report in Codecov by Sentry. |
ok, but I think if the write performance of large files is not satisfactory, it's a matter to consider for object storage. Allocating the cost of increasing disk cache on this side towards improving object storage bandwidth might be a more direct approach. |
I don't get it. Why this change increases disk cache? it only rearranges the upload order, trying to take full advantage of both storage backend. Isn't it better if we can improve performance by optimizing software instead of increasing hardware? |
b568e4a
to
a146039
Compare
…ckend, to have concurrent uploads to two backends, and even double the write bandwidth Signed-off-by: Changxin Miao <[email protected]>
a146039
to
3e36f8a
Compare
Currently, the writeback mode works by writing the block to the staging files first, and then uploading them to the object storage. So the throughput of the writeback mode is limited by the speed of disk. And the max write concurrency is
buffer-size / block-size
which could be overwhelming for some disks.By limiting concurrent writes to staged files and spill others to object backend, we can have concurrent uploads to two backends, and theoretically the write throughput equals to sum of the two (see following experiment).