perf(shard): precompute per-shard offload paths — no per-tick format!/join (#45)#384
Conversation
…/join (#45) The 100ms eviction tick (run_eviction_tick), the memory-pressure cascade (handle_memory_pressure, two sites), the 10s warm-transition check, and the cold-orphan sweep each rebuilt "<offload>/shard-{id}" via format! + PathBuf::join on every firing, per shard — and effective_disk_offload_dir() itself clones a PathBuf per call. That is three allocations per recurring tick per shard on paths CLAUDE.md declares allocation-free, cumulative across N shards forever. Fix, per the issue's suggested shape: the event loop already builds a per-shard `disk_offload_dir: Option<PathBuf>` once at init (Some iff disk-offload is enabled — the same gate that nulls spill_thread and shard_manifest). Thread it into run_eviction_tick and handle_memory_pressure as Option<&Path> and use it directly in the warm-check and orphan-sweep tick arms of both loop flavors (tokio select! and monoio tick counter). Every consumer pairs the dir's Some-guard with its existing disk-offload-implied guard, so behavior is unchanged in every reachable state; the one impossible state (spill machinery live without an offload dir) fails safe to the pre-existing plain-drop branch. Out of scope (event-gated, not recurring): snapshot-trigger path builders (fire only when a save epoch advances), reclamation-schedule persist (is_dirty-gated), and all startup/recovery one-time joins. Verified: full lib suite, both clippy matrices (--all-targets), and the VM offload battery (kill-9 cold-multidb / no-AOF / spill-batch, orphan sweep, collection visibility, DBSIZE, SCAN visibility, shadow resurrection) green with the refactored binary — the battery round-trips spill -> cold read-through -> recovery through the exact paths whose construction moved. Fixes #45 author: Tin Dang <tindang.ht97@gmail.com>
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughDisk-offload shard directories are precomputed and reused across Tokio and monoio maintenance ticks, eviction, memory-pressure handling, warm transitions, orphan sweeps, and spill context creation. ChangesDisk-offload path reuse
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Adversarial review outcome: CONFIRMED-EQUIVALENT. The reviewer proved the load-bearing invariant: Post-review gates: VM crash trio re-run on the final binary (cold-multidb, no-AOF, spill-batch kill-9) all green. |
Summary
Closes #45 (P1-2). The 100ms eviction tick (
run_eviction_tick), the memory-pressure cascade (handle_memory_pressure, two sites), the 10s warm-transition check, and the cold-orphan sweep each rebuilt<offload>/shard-{id}viaformat!+PathBuf::joinon every firing, per shard — andeffective_disk_offload_dir()itself clones aPathBufper call. Three allocations per recurring tick per shard on paths CLAUDE.md declares allocation-free.Fix
The event loop already builds a per-shard
disk_offload_dir: Option<PathBuf>once at init (Someiff disk-offload is enabled — the same gate that nullsspill_threadandshard_manifest). This PR threads it intorun_eviction_tickandhandle_memory_pressureasOption<&Path>and uses it directly in the warm-check and orphan-sweep tick arms of both loop flavors (tokioselect!and monoio tick counter). Every consumer pairs the dir'sSome-guard with its existing disk-offload-implied guard, so behavior is unchanged in every reachable state; the one impossible state (spill machinery live without an offload dir) fails safe to the pre-existing plain-drop branch.handle_memory_pressure's now-unusedserver_configparameter is removed.Out of scope (event-gated, not recurring): snapshot-trigger builders (fire only on save-epoch advance), reclamation-schedule persist (
is_dirty-gated), startup/recovery one-time joins.Verification
clippy --all-targetson both feature matrices,fmt --check.Summary by CodeRabbit