Repository navigation
Reduce multi-Raft image I/O and archive overhead - #98
Merged
Merged
Conversation
Background archive capture could occupy SQL after application work drained, causing the one-shot scan to skip an otherwise eligible leader. Revisit the group within its original one-second turn and the original Node deadline. Add physical-reader regressions for successful handoff and exhausted budget, retaining joined closure. Record the shared-host materialization comparison without claiming an end-to-end speedup. Validation: 630 Rust cases, 40 isolated shutdown repetitions, strict all-target Clippy, formatting, layout, dependency policy and documentation checks.
This was referenced Oct 24, 2026
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
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.
Cellar’s multi-Raft write path builds and publishes independent SQLite images for each cell and replica. This PR reduces avoidable image I/O and scheduling work while preserving quorum acknowledgement, committed-image proofs, bounded resources and RustFS recovery coverage. Main is integrated through
1455fb0; conflicts are resolved.Sustained performance qualification remains incomplete. The overlapping bundle-read experiment is removed after two paired comparisons fail to demonstrate a qualified gain. Active runtime source returns to
5138559and matches all 118 frozen inputs of control0b07410. The experimental commit3d3ba9e, image, correctness tests and raw measurements remain preserved. Rejection reflects insufficient performance evidence, not a claim that shared-host measurements prove a causal regression.Retained changes
Latest comparison: 20 writers, control first
Two 180-second windows per build, each starting with a cold benchmark VM and fresh node volumes. Three pinned 1-vCPU / 3-GiB nodes, 500 leaders and 1,000 followers each, and 1,500 three-voter groups. Frozen source/image/binary identities, load AST and recorded RustFS/Python image identities match. There are no timed mutation retries or changes to durability/admission limits.
Mean successful TPS is 250.81 versus 212.92, a descriptive 15.11% decrease. Both complete repeat sets fail the zero-error gate at 200 and 500 ms. The candidate’s error-free second window alone does not qualify sustained performance.
Sharing is exercised: 7,097 / 4,180 joined reads, or 6.16% / 5.65% of bundle-read admissions. These counters include later failure/cancellation and do not count successful GETs or saved bytes. Retained-entry counters explain all control refusals and 11,748 of the candidate’s 11,749 first-window refusals; the remaining refusal is not attributed to that counter. Publication failures and rejected coverage updates remain zero.
Both builds verify 4,500 exact replica values and 1,500 archive positions, without reconciliation or mutation retries, then stop cleanly with no OOM. Peak node memory is 1.74 GB control / 1.48 GB candidate. Final archive checks take 5.94 / 0.64 seconds; these post-load checks do not establish steady-state drain capacity.
Other builds overlap 37/37 and 38/40 control samples versus 32/37 and 15/36 candidate samples. Host swap ranges from 7.53 to 7.86 GiB. These uncontrolled shared-host conditions prevent causal attribution. This task performs no builds, profiling or preservation during the timed cohorts.
The earlier 24-writer, candidate-first pair was also unqualified: mean successful TPS was descriptively +7.10%, but both first windows had refusals, and the error-free second window had 4.64% lower candidate TPS and 16.81% higher p99. The two pairs use different offered concurrency and are not identical-load reversed confirmation.
20-writer evidence (
tikv-bundle-read-c20.json, retained locally) · 24-writer evidence (tikv-bundle-read.json, retained locally)Environment and validation
The user authorized recreation of
cellar-raft-perfafter a separate Colima reset. The original 352-GiB data disk is reattached with its existing filesystem. All 414 pre-run volumes and 58 images, both frozen binary hashes, and the original mounts were verified. After this pair, all 422 volumes and 58 images remain, with no benchmark containers running. The eight-CPU/16-GiB VM retains the three measured containers’ one-CPU/3-GiB limits. The default profile and selected Docker context are unchanged. Inventory verification is not a full content audit of every historical volume.Restoration validation: 518 library, 53 archive, 19 execution, 29 host and nine multi-group tests pass serially. Three ignored entries are crash-test child helpers exercised by their parents. Strict Cellar all-target/all-feature Clippy, formatting, layout, native dependency policy and docs checks pass. All 118 frozen control source inputs match. Local correctness does not change the failed performance gates; no complete CI claim is made for the new head.
Profile restoration (
tikv-benchmark-profile-recreation.json, retained locally) · Preserved candidate local tests (tikv-bundle-read-local.json, retained locally)TiKV comparison and remaining work
The comparison uses TiKV revision
b3995dab28308f09cbb7c125bf32f789dbc203fe. Itsasync_io/write.rs::write_to_dbshares storage-engine I/O and independently notifies each region Ready after persistence. Cellar’s shared Raft log does not remove independent SQLite preparation, replay and image publication. TiKV’s shared KV apply batch is a structural advantage, not a drop-in replacement for Cellar’s per-cell SQLite contract.Earlier rejected experiments and their measurements remain documented, including admission waiting, independent archive completion, gathered control frames, singleton archive batches and ephemeral capture. No repeatable error-free throughput gain is claimed.
Detailed comparison and complete investigation
Raw benchmark JSON files under
plans/multi-raft/evidence/are excluded from this PR and retained locally. Existing evidence files onmainare unchanged. New local evidence is ignored by Git; the performance and validation summaries remain in this description and the investigation document.