fix: improve perf of msgindex backfill #10941
Merged
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.
Context
When
EnableMsgIndex
is set we maintain a separate sqlite database in.lotus/sqlite/msgindex.db
which maps message cid to the tipset and epoch its stored in. This allows us faster lookup and optimizes several RPC calls.Currently the message index
msgindex.db
uses default journal mode which causes the database to be locked, especially when backfilling this database (usinglotus-shed msgindex backfill
) over multiple epochs (like a FEVM arvhical node). When backfilling, the lotus node will soon lock the database and disable the msgindex logic until next lotus restart which also fails the backfilling itself.This PR addresses these issues by:
lotus-shed msgindex backfill
code to not do writes if message already existsTest plan
Confirmed that backfilling no longer lockes the database and is also 20x+ faster than before: