Skip to content
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

Merged
merged 1 commit into from
Apr 23, 2024

Conversation

polyrabbit
Copy link
Contributor

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).

By setting --max-stage-write=10, we got a write throughput of 5GB/s, almost double the speed of original write. And it lasts for a long time, as long as we have enough space for stage files

image

@jiefenghuang
Copy link
Contributor

This modification may impact the performance in small file scenarios, which are the main focus of write-back optimization.

@davies davies requested a review from SandyXSD April 22, 2024 06:34
@polyrabbit
Copy link
Contributor Author

Then, we expanded write-back scenarios :)

cmd/flags.go Show resolved Hide resolved
cmd/flags.go Outdated Show resolved Hide resolved
pkg/chunk/metrics.go Outdated Show resolved Hide resolved
pkg/chunk/cached_store.go Outdated Show resolved Hide resolved
pkg/chunk/cached_store.go Show resolved Hide resolved
Copy link

codecov bot commented Apr 22, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.38%. Comparing base (f553dcf) to head (3f64165).
Report is 5 commits behind head on main.

❗ Current head 3f64165 differs from pull request most recent head 3e36f8a. Consider uploading reports for the commit 3e36f8a to get more accurate results

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.
📢 Have feedback on the report? Share it here.

pkg/chunk/cached_store.go Outdated Show resolved Hide resolved
@jiefenghuang
Copy link
Contributor

Then, we expanded write-back scenarios :)

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.

@polyrabbit
Copy link
Contributor Author

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?

@polyrabbit polyrabbit force-pushed the current-write branch 2 times, most recently from b568e4a to a146039 Compare April 23, 2024 01:02
…ckend, to have concurrent uploads to two backends, and even double the write bandwidth

Signed-off-by: Changxin Miao <[email protected]>
@SandyXSD SandyXSD merged commit 4609254 into juicedata:main Apr 23, 2024
32 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants