Skip to content

Comments

Move do_durability work into a DurabilityWorker so that it doesn't block the reducer processing core#3868

Closed
Centril wants to merge 2 commits intomasterfrom
centril/durability-worker
Closed

Move do_durability work into a DurabilityWorker so that it doesn't block the reducer processing core#3868
Centril wants to merge 2 commits intomasterfrom
centril/durability-worker

Conversation

@Centril
Copy link
Contributor

@Centril Centril commented Dec 10, 2025

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.

@Centril Centril requested a review from kim December 10, 2025 23:31
@Centril Centril force-pushed the centril/point-scan-abi branch from 10720e1 to fd58ae1 Compare December 11, 2025 01:38
@Centril Centril force-pushed the centril/durability-worker branch from a3357aa to e94ecc7 Compare December 11, 2025 01:41
@Centril Centril force-pushed the centril/point-scan-abi branch from fd58ae1 to 74cc11b Compare December 11, 2025 08:38
@Centril Centril force-pushed the centril/durability-worker branch 2 times, most recently from b278fd2 to 012d454 Compare December 11, 2025 08:43
@Centril Centril changed the base branch from centril/point-scan-abi to master December 11, 2025 08:43
@Centril Centril enabled auto-merge December 11, 2025 08:44
@Centril Centril force-pushed the centril/durability-worker branch from 012d454 to fe7d98b Compare December 11, 2025 08:44
@Centril Centril disabled auto-merge December 11, 2025 09:29
@Centril Centril force-pushed the centril/durability-worker branch from fba1933 to 2a1570a Compare December 12, 2025 00:00
@Centril Centril enabled auto-merge December 12, 2025 00:01
@Centril Centril force-pushed the centril/durability-worker branch from cbe7f3c to 3369347 Compare December 12, 2025 00:23
@Centril Centril force-pushed the centril/durability-worker branch from 3369347 to aef8166 Compare December 12, 2025 08:59
@bfops bfops added release-any To be landed in any release window performance A PR/Issue related to improving performance of stdb labels Dec 15, 2025
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>
@kim
Copy link
Contributor

kim commented Dec 18, 2025

Merged via #3880

@kim kim closed this Dec 18, 2025
auto-merge was automatically disabled December 18, 2025 06:44

Pull request was closed

@Centril Centril deleted the centril/durability-worker branch December 18, 2025 12:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance A PR/Issue related to improving performance of stdb release-any To be landed in any release window

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants