Move do_durability work into a DurabilityWorker so that it doesn't block the reducer processing core#3868
Closed
Move do_durability work into a DurabilityWorker so that it doesn't block the reducer processing core#3868
do_durability work into a DurabilityWorker so that it doesn't block the reducer processing core#3868Conversation
10720e1 to
fd58ae1
Compare
a3357aa to
e94ecc7
Compare
kim
approved these changes
Dec 11, 2025
fd58ae1 to
74cc11b
Compare
b278fd2 to
012d454
Compare
012d454 to
fe7d98b
Compare
kim
approved these changes
Dec 11, 2025
kim
reviewed
Dec 11, 2025
fba1933 to
2a1570a
Compare
cbe7f3c to
3369347
Compare
3369347 to
aef8166
Compare
3 tasks
github-merge-queue bot
pushed a commit
that referenced
this pull request
Dec 17, 2025
Controlled shutdown of a database should drain the outstanding transactions queue(s) and flush them to the durability layer. With the introduction of another queueing layer in #3868, it became harder to observe when or if this process is completed. This patch thus introduces an explicit (async) shutdown method for `RelationalDB` and below, which will wait until all submitted transactions are either reported durable, or an error occurs in the durability layer. `RelationalDB` is made `!Clone`, such that shutdown can be initiated in the `Drop` impl. Note that this requires access to a tokio runtime, which we thread through via the `Persistence` services in order to allow control over which of the various runtimes is being used for durability-related tasks. Also moves `RelationalDB::open` to a blocking thread when a persistence-enabled database is constructed by the `HostController` -- this process performs heavy I/O and can take a substantial amount of time, during which we don't want to block a worker thread. # API and ABI breaking changes None # Expected complexity level and risk 3 # Testing - [ ] some testing added - [ ] existing tests still pass - [ ] `impl Drop for RelationalDB` difficult to test, extra eyeballs needed --------- Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
KirstenWF
pushed a commit
to KirstenWF/SpacetimeDB
that referenced
this pull request
Dec 17, 2025
Controlled shutdown of a database should drain the outstanding transactions queue(s) and flush them to the durability layer. With the introduction of another queueing layer in clockworklabs#3868, it became harder to observe when or if this process is completed. This patch thus introduces an explicit (async) shutdown method for `RelationalDB` and below, which will wait until all submitted transactions are either reported durable, or an error occurs in the durability layer. `RelationalDB` is made `!Clone`, such that shutdown can be initiated in the `Drop` impl. Note that this requires access to a tokio runtime, which we thread through via the `Persistence` services in order to allow control over which of the various runtimes is being used for durability-related tasks. Also moves `RelationalDB::open` to a blocking thread when a persistence-enabled database is constructed by the `HostController` -- this process performs heavy I/O and can take a substantial amount of time, during which we don't want to block a worker thread. # API and ABI breaking changes None # Expected complexity level and risk 3 # Testing - [ ] some testing added - [ ] existing tests still pass - [ ] `impl Drop for RelationalDB` difficult to test, extra eyeballs needed --------- Co-authored-by: Mazdak Farrokhzad <twingoow@gmail.com>
Contributor
|
Merged via #3880 |
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.
Description of Changes
This yields a performance win of about 2k TPS on my machine.
With the whole stack of this PR applied, I'm at 40.5k TPS.
API and ABI breaking changes
None
Expected complexity level and risk
1
Testing
Covered by existing tests.