feat: add configurable io rate limiting for snapshot writes#2802
Open
blindchaser wants to merge 8 commits intorelease/v6.3from
Open
feat: add configurable io rate limiting for snapshot writes#2802blindchaser wants to merge 8 commits intorelease/v6.3from
blindchaser wants to merge 8 commits intorelease/v6.3from
Conversation
|
The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).
|
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## release/v6.3 #2802 +/- ##
================================================
- Coverage 45.96% 43.38% -2.58%
================================================
Files 1199 1866 +667
Lines 104456 155383 +50927
================================================
+ Hits 48008 67419 +19411
- Misses 52227 81955 +29728
- Partials 4221 6009 +1788
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
yzang2019
approved these changes
Feb 4, 2026
cursor bot
pushed a commit
that referenced
this pull request
Feb 5, 2026
- Analyzed snapshot write rate limiting implementation - Validated design decisions and code quality - Identified pre-existing test failure in storev2/rootmulti (unrelated) - Recommendation: APPROVE with minor notes - All tests passing, well-designed global rate limiter approach Co-authored-by: Steven Landers <steven.landers@gmail.com>
Add optional I/O rate limiting for snapshot writes using token bucket algorithm to prevent page cache eviction on systems with limited RAM. Key changes: - New config: sc-snapshot-write-rate-mbps (default: 0 = unlimited) - Global limiter shared across all trees and files using rate.Limiter - Backpressure propagates through entire write pipeline - Added TestGlobalRateLimiterSharedAcrossWriters for validation This addresses high I/O bursts from v6.3 snapshot optimization which can impact page cache efficiency. With rate limiting, operators can trade snapshot speed for more stable I/O patterns. Recommended: 300 MB/s for validators with 128GB RAM (~3 hours per snapshot)
- Hardcode sc-snapshot-writer-limit to 4 (remove from app.toml) - Change sc-snapshot-write-rate-mbps default from 0 to 300 MB/s Rationale: - writer-limit: With rate limiting, this mainly affects CPU overhead rather than I/O throughput. Fixed at 4 provides optimal balance. - rate-limit: 300 MB/s default prevents page cache issues on 128GB RAM validators while maintaining reasonable snapshot time (~3 hours). Users can override rate limit in app.toml (100 for conservative, 0 for high-end machines).
blindchaser
force-pushed
the
yiren/v631-sp-limit
branch
from
979adf7 to
3e7a6f2
Compare
Resolve conflicts in sei-db/sc/memiavl: - db.go: keep CAS (pruningInProgress), snapshotWriteRateMBps, add closed guard from release - db_test.go: use directory state check for prune completion Co-authored-by: Cursor <cursoragent@cursor.com>
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Describe your changes and provide context
Background
v6.3 optimized snapshot creation time from >3 hours to ~20 minutes using aggressive parallel writes. While this improves performance on high-end machines, it can cause high I/O bursts that may impact page cache efficiency on systems with limited RAM.
Solution
Add optional I/O rate limiting for snapshot writes:
sc-snapshot-write-rate-mbps(default: 0 = unlimited)Configuration Example
[state-commit]
sc-snapshot-write-rate-mbps = 300